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!news3.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: Tue, 09 Feb 2010 15:55:20 +0100 Message-ID: <7tdbdtF82bU1@mid.individual.net> References: <7ff3810f-3ee3-4f39-a54c-933ad7d0655c@36g2000yqu.googlegroups.com> <472288fc-b5da-42c4-9e1b-1da1af5de896@q27g2000yqn.googlegroups.com> <7ta6c5Fb1oU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: individual.net NeQ2Bs591EWhKW8k6P1V5w3zx27b3E31t9A8r1B/ROlHe0rAY= Cancel-Lock: sha1:RKkz2/kPiA1brcL8dVIvHPMJHEI= User-Agent: KNode/4.4 rc2 Xref: g2news1.google.com comp.lang.ada:9039 Date: 2010-02-09T15:55:20+01:00 List-Id: Hibou57 (Yannick Duchêne) wrote: > On 8 fév, 11:10, "Alex R. Mosteo" 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.