From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,cb04cee6116c8ced X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Package's private parts and protected types Followup-To: comp.lang.ada Date: Mon, 08 Feb 2010 11:10:59 +0100 Message-ID: <7ta6c5Fb1oU1@mid.individual.net> References: <7ff3810f-3ee3-4f39-a54c-933ad7d0655c@36g2000yqu.googlegroups.com> <472288fc-b5da-42c4-9e1b-1da1af5de896@q27g2000yqn.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: individual.net D6ObEIIt7ySN1uJp4HAUHAuKIroRSt7vk1XDgSsiYkRL8XIbQ= Cancel-Lock: sha1:6Ar4rvpWn5R2bGFOm+9y7ERQ3sk= User-Agent: KNode/4.4 rc2 Xref: g2news1.google.com comp.lang.ada:8968 Date: 2010-02-08T11:10:59+01:00 List-Id: Hibou57 (Yannick Duchêne) wrote: > On 8 fév, 09:30, Martin 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...)