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: a07f3367d7,81bb2ce65a3240c3 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.156.199 with SMTP id y7mr1934883bkw.7.1335714174613; Sun, 29 Apr 2012 08:42:54 -0700 (PDT) Path: h15ni179474bkw.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: sbelmont700@gmail.com Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Sun, 29 Apr 2012 08:42:54 -0700 (PDT) Organization: http://groups.google.com Message-ID: <13229240.2409.1335714174197.JavaMail.geo-discussion-forums@vbuo17> 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> NNTP-Posting-Host: 206.53.78.59 Mime-Version: 1.0 X-Trace: posting.google.com 1335714174 4112 127.0.0.1 (29 Apr 2012 15:42:54 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 29 Apr 2012 15:42:54 +0000 (UTC) In-Reply-To: <12278359.1638.1335669649223.JavaMail.geo-discussion-forums@ynei5> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=206.53.78.59; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-04-29T08:42:54-07:00 List-Id: On Saturday, April 28, 2012 11:20:49 PM UTC-4, Shark8 wrote: > This is plainly false. Consider a cleanup/freeing procedure in a componen= t-based RAD style program* when it is applied to a form having both compone= nts and [sub-]forms which contain both components and forms themselves.=20 >=20 > Having the base COMPONENT with a null procedure for its free is absolutel= y reasonable, especially if the inherited classes need not do anything spec= ial to ensure they are properly disposed of. The form and all of its compon= ent-containing children, however, must do something else: pass the free com= mand to those children. >=20 >=20 > * I'm assuming a class hierarchy with a base COMPONENT type and two branc= hes: the first a CONTAINER class which can hold other components (like visu= al controls); and one, say ITEM, which is for components which cannot have = components added (like a timer). {Yes, this could be done differently, perh= aps with an abstract base-class, but then you have the problem that there i= s no default at all and each actual object of COMPONENT would have to decla= re its own personal free-procedure....} I would still argue that 'null' is not the *default* behavior. The default= of 'free' is to deallocate something, and there are just certain special c= ircumstances where that involves doing nothing. Defaulting to null saves y= ou writing 6 words in these special cases, while circumventing a compile-ti= me check if you forget to implement it in all cases, and that's a bad deal = (and seems orthogonal to everything else in the language). And, as you said, there are other (better) ways this could be done with abs= tract parents, or even better using some sort of auto-deallocation so that = you don't need a 'free' at all. In any case, abstraction should never viol= ate type safety, and if an operation is not appropriate for a type, it shou= ldn't be able to be called at all, and certainly not automatically swept un= der the carpet by the language. Otherwise, where does it stop? If Sea_Pla= ne extends Plane, and Plane has Extend_Landing_Gear, do we make it null bec= ause "it makes sense to be a nop" for a Sea_Plane? What do we do with Retr= act_Landing_Gear? Could the same argument be applied to, say, a Gallon_Of_= Milk type? Landing 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? What would = a post-condition for a null procedure ever be, if there is no gaurentee tha= t anything will ever get done? If you need a null procedure in an interface, then your type hierarchy need= s work. Now that there are interfaces, all it is just shuffling around typ= es. Is it also too much rigmarole to properly organize numeric types into = subtypes so that only applicable values can be used? Why then is is sudden= ly so much trouble to do it for tagged record types so that only applicalbe= operations can be used? With the same example, Plane should be abstract a= nd split into an abstract Fixed_Gear and Variable_Gear, and then Regular_Pl= ane and Sea_Plane derived from each. Calls to manipulate landing gear for = planes that don't have it will fail at compile time. -sb