Re: Constructing an object

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

On Wed, 28 Sep 2005 19:12:40 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:3dachnu33lly.fpr0wvf6nj05$.dlg@40tude.net...
>> On Sat, 24 Sep 2005 00:23:01 -0500, Randy Brukardt wrote:
>>
>>> In Ada 200Y, access discriminants are allowed on nonlimited
>>> types, but they then cannot have defaults (such discriminants cannot change
>>> after object creation, and we needed to disallow changing them via
>>> assignment).
>>
>> How? The type should be then abstract or unconstrained and the user should
>> have rather its subtype with the discriminant limited to the value.
> 
> If the discriminants don't have defaults, the type *is* unconstrained. The
> user has to provide the discriminant value with the object declaration or
> initial value, or from a subtype declaration that is then used to create
> object.

I see, it is same trick as with String.

>> Generics is used to
>> pass the parameters, instead of providing some native mechanism for
>> determining the tag, discriminants, bounds and other constraints.
> 
> We tried a lot of those, but they all fail because Ada allows discriminants
> on tagged types. That makes it necessary for the user code to create the
> object; doing the operations separately is not an option. The only thing
> that I know *would* work (new syntax to allow dispatching on a provided tag
> value) was considered way too heavyweight for a relatively minor problem.
> 
>> One
>> possibility could be to have for each type a predefined null-record type
>> having the same discriminants (tag and bounds are mapped to discriminants).
>> Then the object of this type could be passed to the allocator.
> 
> What allocator? The critical part of the whole scheme is that there is no
> allocator required; this works just as well on stack objects as it does on
> heap-allocated objects. It should never be necessary to use heap-allocated
> objects (or syntax like 'Access and .all) to get the benefits of O-O design.

Sure. But it is just a stack allocator in my view. The idea is that when
you write:

   type T (<constraints>) is ...;
   ...
   X : T (<parameters>);

The compiler would first call function:

   function T'Get_Constraints (<parameters>) return T'Constraints;
   
And T'Constraints is a pre-defined null record type:

   type T'Constraints (<constraints>) is null record;

The user can declare Get_Constraints, or override a predefined one. The
latter happens when the discriminants are visible, so that
<constraints>=<parameters>. The function will evaluate discriminants, array
bounds, the tag (if T is a class-wide type), and put them into that null
record. For array types, the record could contain First, Last components:

   type String'Constraints is record
      First : Positive;
      Last : Positive;
   end record;

This way, I believe, we could have constructors with arbitrary parameters
for all types.

>> IMO there should be proper constructors for all types. Constructing
>> functions are too error-prone.
> 
> No one agreed with that. The only problem with using functions for
> constructors was the weird semantics for limited types, which was solved by
> getting rid of those semantics. If you want to ensure that constructor
> functions are used, you need to declare your types with (<>) discriminants.

That is a minor problem in my view. The real one appears in OO design,
because a function can be overridden only as a whole.

>> Further, Ada needs extensible primitive and
>> class-wide operations, that could finally solve the construction /
>> assignment problem.
> 
> I have no idea what this means; Ada has extensible primitive operations
> (indeed, *only* primitive operations can be extended).

They aren't extensible in the sense that you can only override or inherit.
It is too dangerous for constructors and assignments. BTW, Ada does not to
completely override them anyway. For example the parts responsible for
initialization of the components cannot be overridden. One cannot have a
task component which will not start because Initialize does not call the
parent's one! (:-))

There should be a mechanism for extension of an inherited body available
for user-defined primitive subprograms. It could be extremely useful not
only for constructors, but also for task entries, protected operations,
once they become primitive.

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