Re: What would you like in Ada202X?

[Shark8 <onewingedshark@gmail.com>]

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:
> 
> 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 circumstances where that involves doing nothing.

Which is precisely why it *should* be the default behavior: it is idempotent.
If some component is a clock, then it could have a null deallocation because 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 is 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, the free command needs to ensure that the file is closed and the handle returned to the pool for use.

> Defaulting to null saves you writing 6 words in these special cases, while circumventing a compile-time check if you forget to implement it in all cases,

No, it saves significantly more than that. If it were an abstract method, then EACH component-containing component would need a free procedure AND every non-containing component would need to implement a null-procedure for its 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 language).


Wait, I thought orthogonality was, generally, a good thing.

> And, as you said, there are other (better) ways this could be done with abstract 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 need a 'free' at all.

In all likelihood an auto-deallocate would be an null procedure which is extended 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 operation is not appropriate for a type, it shouldn't be able to be called at all, and certainly not automatically swept under the carpet by the language. 

That's just it though. Thing like the free/deallocate mentioned ARE valid for 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 nop" for a Sea_Plane?  

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 that is the interface.)

>What do we do with Retract_Landing_Gear? 

Exactly the appropriate thing.

> 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?

No. Gallon_of_Milk is not a Plane, therefore there's no reason that it should 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 case that would be a function that just returns True; in Boeing_777's case it would return true only checking that the gear was down.}

> If you need a null procedure in an interface, then your type hierarchy needs work.

Not so; just as my Component AND your Plane examples show. 

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 animals, let's say that there is a Rutting function which returns true if that particular animal can mate (and produce offspring) in things like deer it would involve a lookup into the Calander, in Primates it would simply return 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 subtypes 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 OpenGL binding which wouldn't have allowed bad values to be passed to the parameters.)

> 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, Plane should be abstract and split into an abstract Fixed_Gear and Variable_Gear, and then Regular_Plane and Sea_Plane derived from each.  Calls to manipulate 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 keep the heiarchy more linear (with that point being an "extend from here" for 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 clear 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; say altering how it responds to mouse movement, he doesn't CARE about overriding the free or clear, he just wants to play with the mouse... on the other hand, another user may want to have an ACCELERATED_WINDOW and he has to have a function deallocating that particular handle when he closes the window 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.