Re: Type extension and discriminants

[sbelmont700@gmail.com]

On Saturday, October 11, 2014 2:53:05 PM UTC-4, Dmitry A. Kazakov wrote:
> 
> Don't use this pattern, it simply does not work. Even without GNAT bugs.
> 
> However all GNAT compilers I know have serious problems with more than one
> 
> nested limited return. But if GNAT worked, this pattern will eventually hit
> 
> you back.
> 

The issue of favoring composition over inheritance is that if T1 has lots of operations, especially those which are unchanged (not overridden) for T2 (and T3, and T4, etc), then you end up with the hassle of writing all these one-line delegation methods.  It's easy enough to refactor this so that T1 and T2 both implement interface I, have T2 contain a reference to a T1 and just pass the calls through, but apart from being a PITA and unnecessary, often the compile-time safety is an advantage, not a drawback; any T2 is forced to use T1's (classwide) methods, and can NOT be reconfigured dynamically.  Obviously this a case-by-case sort of thing, but this is certainly a pattern any purportedly OOP language needs to support.

> 
> 
> In short, limited return (constructing function) and limited aggregate are
> 
> not suitable for construction of parent objects which private discriminants
> 
> and components.
> 

+1(000).  This is especially aggravating, because Ada's access discriminants and pass-by-reference semantics are so totally superior for saving references to other objects without having to resort to the heap.  But the intermixing of "true" discriminated records (i.e. variant records, where the structure actually depends on the discriminant), and "fake" discriminated records that just use them when they need a constant always seems to cause endless headaches.  I just wish I had a better idea of how to do it, because C++ initializer lists are a syntax abomination. :'-(


-sb