Allocating "initialized" limited types...

[jsa@alexandria (Jon S Anthony)]

What was the reasoning behind the 4.8(7) definition that an initialized
allocator boils down to an assignment?  Any reason why this could not have
been defined as the creation of an instance with the fields as given by
the qualified expression?

Because of this, allocating limited types with given fields is not very
clean and in some cases requires superfluous conversions.  Maybe someone
knows a clever way out of this?  For example, suppose you have a limited
tagged type and an access type whose designated type is the tagged type's
class:

    type T is tagged limited private;
    type T_Ref is access all T'Class;

Utilizing T_Ref, you construct some general operations constructing
and manipulating hetergeneous lists of things in T'Class.  At certain
places you will want to create these lists by adding to them things
in T'Class provided by allocators of the relevant child types.  So,
you may have something like:

    type C is new T with private;  -- Extends with new fields...
...
    A_List  : Car_Cdr_List_Where_Car_Is_T_Ref;
    Obj_Ref : T_Ref;

    loop
        ...
(1)     Obj_Ref := new C'(....); -- ILLEGAL, assignment to limited type!
        ...
(2)     A_List := Obj_Ref + A_List;
        ...
    end loop

(*) Changing (1) to

        Obj_Ref := new C;
        Obj_Ref.New_Field1 := ... -- ILLEGAL, No such field in this view!
        Obj_Ref.New_Field2 := ... -- ILLEGAL, No such field in this view!
        ...

Doesn't help and is much more prone to errors (forget one of those fields???)
anyway.  So, AFAICT, you need to do the following hack (and it is definitely
a hack...):

Change Obj_Ref's type:

    type C_Ref is access C'Class;  -- or maybe just C...
    Obj_Ref : C_Ref;

Proceed as in (*), which is now legal and change (2) to:

        A_List := T_Ref(Obj_Ref) + A_List;

IMO, this sucks, both because it requires a superfluous conversion and
because of the fact that it still requires error prone field by field
assignment.  Sure, you can isolate this, but that really doesn't
change the fact...  There are a couple other hacks, but they seem even
worse.
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com