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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.231.132 with SMTP id tg4mr5744742pac.31.1389456755090; Sat, 11 Jan 2014 08:12:35 -0800 (PST) X-Received: by 10.49.116.78 with SMTP id ju14mr477qeb.28.1389456755037; Sat, 11 Jan 2014 08:12:35 -0800 (PST) Path: border2.nntp.ams2.giganews.com!backlog4.nntp.ams3.giganews.com!backlog4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!proxad.net!feeder2-2.proxad.net!nx02.iad01.newshosting.com!newshosting.com!news-out.readnews.com!news-xxxfer.readnews.com!209.85.160.88.MISMATCH!a5no8154897pbg.1!news-out.google.com!l9ni14863qay.0!nntp.google.com!p15no8510208qaj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 11 Jan 2014 08:12:34 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=206.53.78.59; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy NNTP-Posting-Host: 206.53.78.59 References: <839fee13-2743-49f6-a7f3-f95578386201@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: 'Protected' abstract subprograms From: sbelmont700@gmail.com Injection-Date: Sat, 11 Jan 2014 16:12:35 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 4781 Xref: number.nntp.dca.giganews.com comp.lang.ada:184396 Date: 2014-01-11T08:12:34-08:00 List-Id: On Friday, January 10, 2014 5:30:55 PM UTC-5, Randy Brukardt wrote: >=20 > You're very confused. Ada takes privacy *very* seriously, something other= =20 >=20 > languages barely try. One of the Ada design's unchangable rules is that t= he=20 >=20 > legality of a client can never be affected by anything in the private par= t=20 >=20 > of tha package. (The private part can only affect the runtime behavior.)= =20 >=20 > We've abandoned many good ideas over the years because of this issue -- i= t's=20 >=20 > the same reason that interfaces cannot be hidden. If we allowed abstract= =20 >=20 > operations in the private part, then the legality of extensions would dep= end=20 >=20 > on the contents of the private part -- or we'd have to convert that into = a=20 >=20 > runtime check rather than a compile-time one, which is the wrong directio= n=20 >=20 > to go. >=20 >=20 Unfortunately, I am often confused :-(. The idea that the private part can= not invalidate the client is a good rule, but there often seems to be excep= tions and loopholes with child packages; i.e. if I extend a type in a child= package by adding a few elements, and then go back and try to add those el= ements to the parent, I get a compile-time name conflict error in the child= . This implies that the child package is not technically a 'client', but j= ust a logical extension of the parent. But if that's the case, then the ch= ild package could also 'see' an abstract subprogram in the private part, an= d could in theory overload it. I'm sure there are all sorts of good reason= s and tradeoffs, but I've had more occasion to want to inherit abstract sub= programs from the private part in a child package then to extend a private = type from a non-child package. >=20 > My recommendation would be to forget it and use dispatching operations=20 >=20 > directly. >=20 To elaborate on the use case, the intent is not to just ferry a static call= to a re-dispatching call, but to use a 'middleman' abstract type to establ= ish reusable code for related groups of implementations. Wikipedia, GoF, e= tc all have better descriptions than I can provide, but the idea is that so= metimes varied implementations will operate mostly the same, but with small= er differences. For instance, Vehicle's abstract 'Move' subprogram might b= e overridden by all manner of plane, train, and automobile, but all the aut= omobiles follow the same basic algorithm (turn key, press accelerator, stee= r, whatever). You create an Automobile class that implements the basic dri= ving algorithm for a Car, but that also adds additional abstract operations= that represent the particulars (e.g. Turn_Key). The Drive operation dispa= tches to these new operations to implement the algorithm. Now each concret= e car type only has to implement the few new additional operations however = it sees fit, and the inherited drive operation eliminates duplicating the s= ame algorithm over and over and over for every Car. Again, it works by just making these publically visible, which is not norma= lly not a big deal since the clients work with the Vehicle'Class anyway, bu= t pedantically the operations should be hidden from everything except the c= hildren and not have default implementations, and it's unfortunate that Ada= makes you pick one or the other. Thank you everyone for your responses. -sb