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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.89.68 with SMTP id d4mr29399444qam.8.1373369092262; Tue, 09 Jul 2013 04:24:52 -0700 (PDT) X-Received: by 10.49.35.195 with SMTP id k3mr678069qej.2.1373369092242; Tue, 09 Jul 2013 04:24:52 -0700 (PDT) Path: border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!t19no891428qam.0!news-out.google.com!f7ni1652qai.0!nntp.google.com!t19no891426qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 9 Jul 2013 04:24:52 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=20.133.0.8; posting-account=g4n69woAAACHKbpceNrvOhHWViIbdQ9G NNTP-Posting-Host: 20.133.0.8 References: <69246de0-4b33-4d47-b5be-a45e8c911fb0@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada202X: Easy to use "UML private"-like components From: Martin Injection-Date: Tue, 09 Jul 2013 11:24:52 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 4736 Xref: number.nntp.dca.giganews.com comp.lang.ada:182371 Date: 2013-07-09T04:24:52-07:00 List-Id: On Friday, June 21, 2013 7:36:40 PM UTC+1, Robert A Duff wrote: > Martin writes: > Secondly, I have to explain that = using Ada "private" gives you "UML protected": Not exactly. Ada "private" m= eans clients can't see it, but child packages (which should be thought of a= s part of the same abstraction) can. It's a completely different visibility= model than UML. I don't see any reason to be embarrassed about that. > Opt= ion 2: > type T is tagged record > null; > private > F : Float; > end recor= d; > > > I prefer Option 2. > > Thoughts? I don't think making Ada more lik= e UML is a worthwhile goal. If it were, I'd prefer your option 1. But I don= 't see the point: In Ada, packages are about visibility. That's different f= rom languages that conflate the concept of "module" and "type" (which has b= oth advantages and disadvantages). Overall, I prefer the Ada way. If you wa= nt derived types to see their parent types components, you put the derived = types in a child package; if you don't, then you don't. Attempts to mimic U= ML in Ada lead to a mess, as you've shown. I share your disdain for what yo= u called "opaque" types -- it forces you into heap management, which leads = to extra trouble. But I object to calling them "opaque" types. Ada folks us= ually call them "stt access types" and "stt incomplete types", or "Taft ame= ndment types", because they were invented by Tucker Taft and added to Ada 8= 3 at the last minute when nobody realized all the headaches they cause for = compiler writers. The term "opaque type" comes from Modula-2, IIRC, and is = more like an Ada private type, with some annoying restrictions added. - Bob Back from holiday...I'll leave all the Modula-2 discussion well alone. I wa= s just using "opaque" in the English dictionary definition sense - no impli= cation of links to other languages implied...but thanks for the background! I hindsight, all the recent changes to Ada-syntax style probably does favou= r Option 1. Anyway, the keyword in the topic was "easy" - perhaps I should have written= it in ALL-CAPS :-) There are current options of how to achieve UML-like private-ness but all a= re clunky and some are horrific and, given their access-types not available= for safety-critical systems (where coding standard still often forbid such= usage). As to making Ada more UML-like, that's not really my goal...but I'd certain= ly like to make common UML constructs easy to achieve in Ada. It's a topic I've raised at various conferences for 10 years or more. I had hoped a standard UML <-> Ada mapping could be agreed between the UML = & Ada compiler tool vendors; certainly they all gave positive responses to = such a move all those years ago. They all had company's developing their ow= n Stereotype/Tag UML<->Ada solutions, so all saw this wheel being re-invent= ed year after year, company after company. Sadly, I expect the companies who were re-inventing these wheels, saw their= work as "IP" and not to be shared with the wider community. Opportunity lo= st. Interest has been raised in UML/Ada recently but sadly the current state-of= -the-art is not as mature as the current UML/Java or UML/C++...and I live i= n a MDA focused s/w dept, where UML is a must and where auto-code generatio= n is much used. NB: Lots of recent s/w grads seem to be literal in only in UML + Java...it = have become, for better or for worse, a UML world. -- Martin