Re: Package's private parts and protected types

["Alex R. Mosteo" <alejandro@mosteo.com>]

Hibou57 (Yannick Duchêne) wrote:

> On 8 fév, 11:10, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:
>> Frankly, these non-orthogonalities about regular and protected/tasks
>> types were really nagging me in Ada95 (the dot notation only for these
>> types, for instance, and the visibility of privates that you point to).
>> Now at Ada05, it's the mix of traditional and OO notation caused by
>> interfaces what bugs me.
> Although I've never confessed it here at comp.lang.ada, I feel the
> same too, at least about notation. Luckily, Ada still allow me to
> preserve consistency granting me the choice to use a dotted notation
> or not : I never use the dotted notation for consistency and clarity
> purpose (except that it's mandatory with protected types and tasks,
> and that's ok for me with record components, as it's implementation
> level).
> 
>> Also, the fact that making a protected version of a regular object
>> involves so much boilerplate code is a regular déjà-vu that pains me in
>> my dreams (;-)), compare it to java where adding the keyword synchronized
>> is enough. (Not that I would want java granularity for synchronized; the
>> bugs I've seen caused by "clever" overoptimization of critical
>> sections...)
> I could not tell about comparison between Java and Ada at this point,
> as I've never experienced tasking with Java (I use to self-learn Java,
> but quickly leave it for some reasons). While the point you've spotted
> seems interesting.

My Java is fairly rusty, but if I'm not mistaken, the thing is like this 
(corrections welcome!):

(A)
public class Blah { ... } // A regular class

public synchronized class Blah  {} // All subprograms of Blah are now 
thread-safe.

However, you can also:

(B)
public class Blah
{
 public synchronized get() {}
 public synchronized set() {}
 public bang() {}

}

So basically you choose which methods are synchronized. Or, even further:

(C)
public class Blah
{
 public void set() {
   synchronized(this) {    
      // Using this as the lock, operate exclusively within this block.
   }
 }
}

In my (limited) observing experience, programmers with a tendency to 
premature optimization (we all start like that, I fear) avoid (A) because 
it's seen as too restrictive. (I don't actually know if Java has a read-only 
lock and write lock model like Ada, or using (A) makes all subprograms 
mutually exclusive).

So they tend to rely on (B) or (C). At that point, it's really too easy to 
somewhere, sometime, forget about a necessary lock, and funny heisenbugs 
start to happen caused by obscure race conditions.

I really love the tasking+protected model of Ada.