Re: Construction initialization problem

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 4 Dec 2008 16:17:56 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:oscmgxrpod50$.g7h7snlssha0$.dlg@40tude.net...
>> Consider this:
>>
>>   type A is tagged limited null record;
>>   type B (X : not null access A'Class) is tagged limited null record;
>>
>> Now we want to specialize B so that its instances would already contain A:
> 
> You never explained why you would want the discriminant in the first place.

Huh, that is a mix-in, a major excuse for not to have multiple inheritance
in Ada!
 
> I would think that it would be better to do what you've said about C 
> (include the instance directly in it) from the beginning, and the problem 
> doesn't come up.

No, in the case I have in mind, mix-in is appropriate. Consider layered
network protocols. "A" were a transport layer. "B" were a protocol. There
can be many different transports for the same protocol so an implementation
of B shall dispatch to the operations of A. If B would inherit to A that
would require permanent conversions to A'Class inside the operations of B
(=a mess). Now consider that at some point you decided which transport
(some type derived from A) and which protocol (some type derived from B) to
take. You want to put it all into one opaque object. That would be the type
C. But you cannot, without pointers and dynamic allocation. Welcome back to
C++!

> Access discriminants have a fairly high overhead in Ada (because of the 
> possibility of coextensions), so unless you *need* coextensions, they ought 
> to be avoided.

Do you mean space or time overhead?

> One could use a named access type instead to declare the discriminant if you 
> really need a discriminant.

You mean an access component? But because Ada has no proper construction,
there is no way to use not-null access components. OK, I know and in fact
use one, but it is very intrusive.

> But the only time you must use a discriminant is 
> if you have a discriminant-dependent component, and there is no interesting 
> way to make a component dependent on an access discriminant. So I'd prefer 
> to just avoid the discriminant.
> 
> If you're using discriminants to stand in for a proper constructor, I say 
> "don't!!" Use a constructor function as the language intends (and force it 
> with a (<>) if you need it).

Oh no, been there. The problem arose from inability to write such a
function! You must be able to write an aggregate to return it from the
function. The components of the aggregate will have the constraints
impossible to spell.

----------------------------
The language problem is lack of abstraction. If there were abstract access
types, then you could make an instance of A implement the interface of
"access A" and them simply put an object of A as a discriminant for B:

   type AA is new A and access A with null record; -- A and access to A
   overriding function "'Access" (X : A) return access A;
   function Create return AA; -- Creates an instance of AA
   B_with_A : B (Create); -- Constrain it by an object

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de