Package's private parts and protected types
in [ADA]
|
From: Hibou57 (Yannick Duchêne) on 8 Feb 2010 05:46 On 8 fév, 11:10, "Alex R. Mosteo" <alejan...(a)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.
From: Hibou57 (Yannick Duchêne) on 8 Feb 2010 05:54 On 8 fév, 11:20, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Mon, 8 Feb 2010 00:30:12 -0800 (PST), Martin wrote: > > This is true of task types too. > > I don't think so. The task specification does not expose barriers and local > variables of its body. But the protected type specification does its > private operations and components: I still think so :p What about a task entry which should be accessible by some entities of the package implementation ? I'm not talking about these task's private entries intended for Requeue, I'm talking about an entry which should be publicly available while still being available, not only from the task itself, and also from the package body which hold the task implementation. > Obviously to me, the syntax should have been like: > > type T is protected private; -- or "protected with private" > entry Foo (X : in out T); > function Bar (X : T) return Boolean; > private > type T is protected record > ... So, with absolute majority, the Gang Of Three voted there is a flaw here Yes, I would have enjoyed too a "protected [with] private". > end T; -- I don't like "end record" either. This makes me remind I will have to later reply to another thread where you also talking about some other stuff you don't like
From: Hibou57 (Yannick Duchêne) on 8 Feb 2010 05:58 Tipo error : I'm talking about an entry which should *not* be publicly available instead of I'm talking about an entry which should be publicly available
From: Dmitry A. Kazakov on 8 Feb 2010 06:01 On Mon, 8 Feb 2010 02:54:17 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote: > On 8 f�v, 11:20, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> On Mon, 8 Feb 2010 00:30:12 -0800 (PST), Martin wrote: >>> This is true of task types too. >> >> I don't think so. The task specification does not expose barriers and local >> variables of its body. But the protected type specification does its >> private operations and components: > I still think so :p > What about a task entry which should be accessible by some entities of > the package implementation ? I'm not talking about these task's > private entries intended for Requeue, I'm talking about an entry which > should be publicly available while still being available, not only > from the task itself, and also from the package body which hold the > task implementation. Yes, OK. Maybe it is not so offending as private components of a protected type, but you are right. "C++-ish" notation (wasn't it actually before C++?) poison is at work here as well. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Georg Bauhaus on 8 Feb 2010 08:19
Dmitry A. Kazakov schrieb: > On Mon, 8 Feb 2010 02:54:17 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote: > >> On 8 f�v, 11:20, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> >> wrote: >>> On Mon, 8 Feb 2010 00:30:12 -0800 (PST), Martin wrote: >>>> This is true of task types too. >>> I don't think so. The task specification does not expose barriers and local >>> variables of its body. But the protected type specification does its >>> private operations and components: > >> I still think so :p >> What about a task entry which should be accessible by some entities of >> the package implementation ? I'm not talking about these task's >> private entries intended for Requeue, I'm talking about an entry which >> should be publicly available while still being available, not only >> from the task itself, and also from the package body which hold the >> task implementation. > > Yes, OK. Maybe it is not so offending as private components of a protected > type, but you are right. "C++-ish" notation (wasn't it actually before > C++?) poison is at work here as well. Perhaps a combination of Eiffel's visibility sets and Ada's seperation of spec and body? |