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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.223.40 with SMTP id qr8mr2626002pbc.0.1335742165123; Sun, 29 Apr 2012 16:29:25 -0700 (PDT) Path: r9ni113705pbh.0!nntp.google.com!news2.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Sun, 29 Apr 2012 16:29:24 -0700 (PDT) Organization: http://groups.google.com Message-ID: <25563681.2104.1335742164732.JavaMail.geo-discussion-forums@ynee1> References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <13849842.838.1335485882969.JavaMail.geo-discussion-forums@vbai3> <134641.307.1335542673651.JavaMail.geo-discussion-forums@pbrx5> <2867357.127.1335561067669.JavaMail.geo-discussion-forums@ynee1> <12278359.1638.1335669649223.JavaMail.geo-discussion-forums@ynei5> <13229240.2409.1335714174197.JavaMail.geo-discussion-forums@vbuo17> NNTP-Posting-Host: 96.2.54.122 Mime-Version: 1.0 X-Trace: posting.google.com 1335742165 520 127.0.0.1 (29 Apr 2012 23:29:25 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 29 Apr 2012 23:29:25 +0000 (UTC) In-Reply-To: <13229240.2409.1335714174197.JavaMail.geo-discussion-forums@vbuo17> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=96.2.54.122; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-04-29T16:29:24-07:00 List-Id: On Sunday, April 29, 2012 10:42:54 AM UTC-5, sbelm...@gmail.com wrote: > On Saturday, April 28, 2012 11:20:49 PM UTC-4, Shark8 wrote: >=20 > I would still argue that 'null' is not the *default* behavior. The defau= lt of 'free' is to deallocate something, and there are just certain special= circumstances where that involves doing nothing. Which is precisely why it *should* be the default behavior: it is idempoten= t. If some component is a clock, then it could have a null deallocation becaus= e it only needs to be able to read (and process) the computer's clock; this= means there are only procedures associated with this object, as the data i= s the time (likely memory-mapped) and to "free"/zero-out that data would at= best do nothing, at worst reset the clock to some incorrect time. On the other hand if it (the component) is something like a file parser, th= e free command needs to ensure that the file is closed and the handle retur= ned to the pool for use. > Defaulting to null saves you writing 6 words in these special cases, whil= e circumventing a compile-time check if you forget to implement it in all c= ases, No, it saves significantly more than that. If it were an abstract method, t= hen EACH component-containing component would need a free procedure AND eve= ry non-containing component would need to implement a null-procedure for it= s free-method (remember, with a base-class being abstract it needs to have = a valid FREE method in order to be a concrete object/class). >and that's a bad deal (and seems orthogonal to everything else in the lang= uage). Wait, I thought orthogonality was, generally, a good thing. > And, as you said, there are other (better) ways this could be done with a= bstract parents, I did not say "better", I said there were other ways (without weighing the = general-designs against each other at all). > or even better using some sort of auto-deallocation so that you don't nee= d a 'free' at all. In all likelihood an auto-deallocate would be an null procedure which is ex= tended by the other classes. (i.e. doing what we've described, but in this = case hidden from the programmer.) > In any case, abstraction should never violate type safety, and if an oper= ation is not appropriate for a type, it shouldn't be able to be called at a= ll, and certainly not automatically swept under the carpet by the language.= =20 That's just it though. Thing like the free/deallocate mentioned ARE valid f= or all types in that class-hierarchy, it's just that (even as you admitted)= sometimes it's a NOP. > Otherwise, where does it stop? If Sea_Plane extends Plane, and Plane has= Extend_Landing_Gear, do we make it null because "it makes sense to be a no= p" for a Sea_Plane? =20 Well, if Plane is an interface with Extend_Landing_Gear, and Sea_Plane uses= Plane, then you bet it does. (Otherwise Sea_Plane violates the contract th= at is the interface.) >What do we do with Retract_Landing_Gear?=20 Exactly the appropriate thing. > Could the same argument be applied to, say, a Gallon_Of_Milk type? Landi= ng gear operation is just as applicable to a Sea_Plane as it is to a Gallon= _of_Milk, yet one is OK but the other is not? No. Gallon_of_Milk is not a Plane, therefore there's no reason that it shou= ld have Extend_Landing_Gear... unless you're making it implement the PLANE = interface. > What would a post-condition for a null procedure ever be, if there is no = gaurentee that anything will ever get done? Easy; Post condition would be True. (Always succeed.) Or, going back to the Plane example, perhaps Extend_Landing_Gear has a post= _condition of "Landing_Gear_Deployed" returning true. {And in Sea_Plane's c= ase that would be a function that just returns True; in Boeing_777's case i= t would return true only checking that the gear was down.} > If you need a null procedure in an interface, then your type hierarchy ne= eds work. Not so; just as my Component AND your Plane examples show.=20 The same argument could be made against a function that returns a constant = for an entire [sub-]hierarchy. And in fact, lets move to the hierarchy of a= nimals, let's say that there is a Rutting function which returns true if th= at particular animal can mate (and produce offspring) in things like deer i= t would involve a lookup into the Calander, in Primates it would simply ret= urn true: thus making monkeys and humans have "no mating season." > Now that there are interfaces, all it is just shuffling around types. Is= it also too much rigmarole to properly organize numeric types into subtype= s so that only applicable values can be used? What are you talking about? I do this a lot and would be surprised if others here didn't. (In fact, before my HD crashed a year ago I was working on a very-thick Ope= nGL binding which wouldn't have allowed bad values to be passed to the para= meters.) > Why then is is suddenly so much trouble to do it for tagged record types = so that only applicalbe operations can be used? With the same example, Pla= ne should be abstract and split into an abstract Fixed_Gear and Variable_Ge= ar, and then Regular_Plane and Sea_Plane derived from each. Calls to manip= ulate landing gear for planes that don't have it will fail at compile time. Even if you could get by with an "If Plane not in Fixed_Gear" [...] for a general auto-landing program, why = should that heirchy be forced into such a split? Suppose someone wants to k= eep the heiarchy more linear (with that point being an "extend from here" f= or users)? Specifically, I could see it being useful for GUI-programming; as was said = about having callback-hooks suppose you had a WINDOW component and attached= some OpenGL handler to it, then maybe it would make sense to have the clea= r or free (or whatever) be null and only overriden when it needed to be. (What I'm saying is that some user could have FUN_WINDOW extend WINDOW w/o = having to mess with anything except the items/properties he's working on; s= ay altering how it responds to mouse movement, he doesn't CARE about overri= ding the free or clear, he just wants to play with the mouse... on the othe= r hand, another user may want to have an ACCELERATED_WINDOW and he has to h= ave a function deallocating that particular handle when he closes the windo= w but doesn't give a crap about the mouse input.) That is to say, a NULL procedure may be a valid alternative to providing an= abstract class especially when there would be numerous methods that would = need to be defined in order to derive even one of those branches.