Re: What would you like in Ada202X?

[sbelmont700@gmail.com]

On Saturday, April 28, 2012 11:20:49 PM UTC-4, Shark8 wrote:

> This is plainly false. Consider a cleanup/freeing procedure in a component-based RAD style program* when it is applied to a form having both components and [sub-]forms which contain both components and forms themselves. 
> 
> Having the base COMPONENT with a null procedure for its free is absolutely reasonable, especially if the inherited classes need not do anything special to ensure they are properly disposed of. The form and all of its component-containing children, however, must do something else: pass the free command to those children.
> 
> 
> * I'm assuming a class hierarchy with a base COMPONENT type and two branches: the first a CONTAINER class which can hold other components (like visual controls); and one, say ITEM, which is for components which cannot have components added (like a timer). {Yes, this could be done differently, perhaps with an abstract base-class, but then you have the problem that there is no default at all and each actual object of COMPONENT would have to declare 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 circumstances where that involves doing nothing.  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, 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 abstract 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 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.  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?  What do we do with Retract_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 that anything will ever get done?

If you need a null procedure in an interface, then your type hierarchy needs work.  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?  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.

-sb