Re: Help - Constructors - ASAP.

[Mats Weber <Mats.Weber@elca-matrix.ch>]

dennison@telepath.com wrote:

> I see. I thought you were somehow passing back an object of the right class
> for the context.

No, because you can't do this.

package Parent is

   type T is tagged private;

   function Construct return T'Class;
      -- Class-wide just to make it non-primitive.

end Parent;


with Parent;

package Child is

   type T is new Parent.T with private;

end Child;

As Parent has no knowledge of Child, its constructure cannot be modified to
return a Child.T. It will always return a Parent.T, which will raise
Constraint_Error in the following case:

declare
   X : Child.T := Parent.Construct;
begin
   ...

> But, a naieve reader would look at that and think that they could get back an
> object of *any* type in the class (as I have just proven :-) ), when in
> actuality they always get back the same class of object.

This means that you should not mess with tagged types as long as you are still
naive :-)

> If I read you correctly, what you were worried about was developers screwing
> up and forgetting to override the default constructors. Nothing about this
> solution prevents that. Now instead of getting the default constructor, our
> hapless client will compile with the class-wide constructor. They get an
> exception at runtime either way. But now the client, who is just as capable
> of screwing up as the subclass author, could goof and use the class-wide
> constructor on his own.

This seems to show that non-primitive _and_ non class-wide constructors are
preferable (e.g. using the nested package or child package approach).