Re: What would you like in Ada202X?

[Adam Beneschan <adam@irvine.com>]

On Friday, April 27, 2012 4:40:50 PM UTC-7, sbelm...@gmail.com wrote:
> On Friday, April 27, 2012 7:18:34 PM UTC-4, Randy Brukardt wrote:
> 
> > Note that Ada 95 did that (implicitly) for the Initialize/Adjust/Finalize 
> > routines of type Controlled. We made that more explicit in Ada 2005, but 
> > that did not reflect any language change. This is another example of a 
> > "hook".
> 
> But this, along with the other hooks, seems like a relic of a single-inheritance version of Ada.  A much (well, perhaps just slightly) better version would be to split things up into multiple interfaces.  For instance, instead of just extending Ada.Finalization and getting all three hooks regardless, you split the three routines into three different one-subprogram interfaces.  Types extend exactly which ones they want, and not the ones they don't.  If you don't want Finalization or Initialization, then you only extend the Ada.Finalization.Adjustable (e.g.), and you no longer have usless subprograms being called to perform usless actions, and any mistakes (forgetting to implement one, trying to implement another, etc) are caught at compile time.  Types get exactly what they ask for, and nothing they don't.  Why leave to a human what can be done by the compiler?

How is this possibly going to work with class-wide types?  Sure, it's not common to call Initialize/Adjust/Finalize directly in a program, but consider some other abstract type T that has procedure methods A, B, and C.  For one type T1 derived from T, it makes sense that A and B would be no-ops.  For another type T2 derived from T, A and B would do something.  Maybe for another derived type T3, A would do something but C would be a no-op.  Now you want to write a procedure that takes an argument Obj of type T'Class (or access-to-T'Class), and that procedure wants to call method A and/or B and/or C (and is perfectly fine with one or more of those procedures being no-ops).  How can it do this, if you say A, B, and C can't be defined as primitives of type T but have to be defined in some other interface or something like that?  Whatever solution you're going to come up with, it's not worth it.  It would require a lot of rigmarole to implement a rather common situation, and requiring all that extra junk seems likely to make things more error-prone than the problem you're trying to solve.  

                       -- Adam