Re: Package's private parts and protected types

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

Hibou57 (Yannick Duchêne) wrote:

> On 8 fév, 09:30, Martin <martin.do...@btopenworld.com> wrote:
>> This is true of task types too.
> Indeed
> 
>> We take the view that if something was a task/protected or not should
>> be hidden from a user (e.g. we may change the behaviour from being
>> task based/not protected, so we abstract away that information).
> 
> Your suggestion seems to confirm a feeling I was expressing in a
> previous thread :
> 
http://groups.google.com/group/comp.lang.ada/browse_thread/thread/385c146dd3112519?hl=fr#
> (sorry for pure Usenet user, it's a google-newsgroup link)
> 
>> [...]
>> Any way, a request made to a task is blocking as long as the task is
>> not ready to fulfill the request (the rendezvous, which is the Ada
>> primitive for synchronization). So, from the client point of view, a
>> method implemented on top of a task is not a different thing than a
>> method implemented on top of a procedure.
>> [...]
> 
> 
>> The associated 'rule' for callers is that they can't assume that calls to
>> any operation don't block - but that's true of calling pretty much any
>> package anyway.
> On one hand, an implementation level detail
> On the other hand, something which I feel should be part of the
> interface.
> I would like to underline : “ part of the interface ”, because while I
> was writing these four words, I though “ part of the interface... but
> what about the specification ? ”
> 
> Most of time I use the words Interface and Specification as
> equivalent, but there, I see it's not the same. Blocking, is unlikely
> to be part of any required specification. In the mean time, None-
> Blocking, is most likely to be a specification requirement.
> 
> So : implementation detail or mediumly part of specifications ?
> 
>> I wonder if there is room for "pragma (Not_)Blocking"?...Not just as a
>> visual aid but maybe it could also be used extend the usage of "pragma
>> Detect_Blocking" to wrappers for "foreign languages".
> This sounds good to me in someway (I mean providing the latter
> question can be answered), as I was also on my side, thinking about a
> similar thing : should or should not, Ada, have a keyword or a pragma
> to tell a particular method is potentially blocking ?
> 
> In the other thread I've pointed, someone suggested me tasks as record
> components is most of time not a good idea. But as the only way to
> hide private features, is to wrap the target item in a private record
> (possibly tagged by the way) type, I wonder what was the reason of
> this suggestion to avoid it.
> 
> Do you have on you side some feedback to give about experiencing with
> task wrapped in private records ? What may be the shortcomings or
> traps when using tasks as record components ?

I have used tasks as record components in (that I can remember) 
communication related types. My rule of thumb is that as long as the type 
lifespan is the whole app lifespan, or the type lifespan is derived from the 
task lifespan (i.e. end of tasking marks the end of the object, and not the 
other way around), things don't present any surprises. With the caveat that 
sjw pointed for dynamic deallocation.

I cannot remember any unusual difficulties about it, but I'm only a 
practitioner so it's possible I'm also missing some theoretic or obscure 
reason to try to avoid it.

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.

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...)