Re: Proposal: Constructors, Assignment [LONG]

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

Randy Brukardt wrote:

Thank you for the response.

> I think that for this proposal to get serious consideration, you'll have
> to give rules to plug the many holes in it:
> 
> -- You'd need to carefully explain why solutions based on functions (as
> Nick Roberts described) are not sufficient;

They cannot work when no assignment exists. Otherwise one should invent a 
sort of pickwickian assignment.

> -- You'll need to explain how this works for controlled types (an
> incompatibility there is simply not going to be tolerated);

I do not think that there is any incompatibility. Initialize can be treated 
as an overriding of 'Initialize.

> -- You'll need to determine the rules for these in generics. Your
> current description would be a giant contract model violation, and that
> needs to be fixed. In particular, for a generic formal private type:
>    generic
>       type Priv is private;
> what 'Get_Constructor and 'Initialize routines can be called? The fact
> that these are different in profile is simply not going to fly here (and
> I doubt that banning the use of constructors in generic bodies is going
> to be an acceptable solution).

It is not a ban. It is just a contract. Priv is private, as such it has only 
the standard copy-constructor (because there is an assignment). No more. 
Why should we expect that every user-defined operation on any possible 
actual for Priv should be visible in the generic body? If that is an intent 
then one should do:

generic
   type Priv is new Type_That_Has_Interesting_Constructors with private;

Here Priv can use all primitive operations defined on 
Type_That_Has_Interesting_Constructors and user-defined constructors too.

I suppose the fact that this works for tagged types only is not a fault of 
my proposal. (:-))

An we still can have nasty, but working:

generic
   type Priv is private;
   with function My_Favorite_Operation (X : Priv) is <>;
   ...
   with function Priv'Get_Constraints (...) return ... is <>;
   with procedure Priv'Initialize (...) is <>;

> -- You'll need to explain how this works in the face of disappearing
> components on an assignment. That has been the problem that has killed
> all previous proposals like this one. See
>     http://www.adaic.org/standards/95aarm/html/AA-7-6.html, paragraphs
> 17.a-17.h for a discussion.

It works same way it works for the controlled types. Compare:

A. Controlled type assignment:

A.1 Check constraints (obtained from source)
A.2 Finalize target
A.3 Copy bit-wise
A.4 Call Adjust

B. Assignment generated from a constructor

B.1 Get constraints from the parameters (call to 'Get_Constraints)
B.2 Check constraints
B.3 Finalize target
B.5 Call 'Initialize

My point is that one can always generate an assignment from a constructor. I 
do not propose to allow user-defined assignments written in a form a 
subroutine. I propose that all assignments be generated out of 
constructors, user-defined ones inclusive.

> I'd prefer making the function solution work. There is a proposal to
> make it possible to initialize limited objects with a function call,
> which would eliminate that objection.

Yes it definitely would, because a function which result initialises an 
unconstructed object is just another name for constructor. However there 
would be also questions:

1. Will you use ":=" for limited types within a declaration with a problem 
to explain what is that, or just "rename"?

2. What to do with "new" for limited types, when a constructor have to be 
called?

3. I suppose that constructors will be allowed for Limited_Controlled only? 
So arrays, untagged types, tasks and protected object will remain out of 
reach.

> Your other objection:
> 
>>The idea that a constructor is just a function is IMO badly wrong.
> Limited
>>types is just one example why. Another example is class-wide types. How
> to
>>construct a class-wide object from scratch? To write a class-wide
> function?
>>But then it will never ever dispatch. A dispatching one? But the type
> is
>>unknown and there is no object. This is why Ada's stream attributes are
>>made hard-wired. This is also why assignment is a problem.
> 
> 
> The bug, IMHO, is that you can't write T'Class'Input in Ada. Its
> terrible that magic is needed there, because its clear that there are
> other cases where that sort of code would be useful.
> 
> We investigated some solutions to that problem in the past. The primary
> problem is how to get the object created for a particular value of
> Ada.Tags.Tag. A direct approach doesn't work, because you don't know how
> to initialize the discriminants (they can be different for extensions
> than for the base type). However, an approach based on using the tag
> value to control dispatching of a function (rather than a result object)
> does work. And it is very simple to implement (as compilers are
> essentially dispatching on a value of Ada.Tags.Tag anyway). However,
> most people thought that inventing syntax to solve this problem was too
> heavy, and there really isn't any alternative. So nothing much has been
> done on this problem.
> 
> The basic idea is to somehow figure a value of Ada.Tags.Tag, then use it
> to control dispatching on a function that returns the correct kind of
> object. This requires a special call:
> 
>       Obj : T'Class := Func (<args>) use Tag_Value;

The question is, will dispatching without an object be useful in cases other 
than construction? This proposal requires new syntax. Mine

   Obj : T'Class (<args>);

requires only new attributes. And gives

   new T'Class (<args>);

   subtype Specific_T is T (<args>);

almost for free.

> With these two capabilities, I believe that functions provide
> appropriate constructors, and you don't necessarily need to use a
> 'handle' implementation. (I suspect that in practice, you often will
> want to use a handle implementation anyway, but I certainly agree that
> you shouldn't be forced into it.) Leveraging existing language features
> is far preferable to inventing a whole new mechanism.

Though it is another question, I think that there is a need to have 
something like user-defined anonymous access types, with the operations 
becoming primitive for the pointed type. But it is probably far more 
difficult than just constructors.

-- 
Happy New Year,
Dmitry A. Kazakov
www.dmitry-kazakov.de