Freezing question

Freezing question

[Ted Dennison]

I have a problem with operations that don't seem to be getting
inherited. I think it may be caused by a type being prematurely (for me
anyway) frozen. I can't quite make out the LRM freezing rules. So I
thought I'd ask here, does the second declaration below:

   type Fruit is abstract tagged private;
   type Apple is abstract new Fruit with private;

freeze type "Fruit"?

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Freezing question

[Tucker Taft]

Ted Dennison wrote:
> 
> I have a problem with operations that don't seem to be getting
> inherited. I think it may be caused by a type being prematurely (for me
> anyway) frozen. I can't quite make out the LRM freezing rules. So I
> thought I'd ask here, does the second declaration below:
> 
>    type Fruit is abstract tagged private;
>    type Apple is abstract new Fruit with private;
> 
> freeze type "Fruit"?

No.  A private extension does not freeze its ancestor type.
A record extension does freeze its parent type.
If something is not being inherited, it might be because you
are declaring the type in something other than a package spec.
Only tagged types declared immediately within a package spec end
up with inheritable primitive subprograms.

I suppose another problem is that, for a private extension, the
set of inherited operations is determined by those of the ancestor
at the point where the private extension is declared.

If freezing were your problem, you would get error messages from
the compiler, rather than mysterious loss of inheritance.


> T.E.D.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Freezing question

[Ted Dennison]

In article <378E57FE.FA7EEB99@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Ted Dennison wrote:

> >    type Fruit is abstract tagged private;
> >    type Apple is abstract new Fruit with private;

> I suppose another problem is that, for a private extension, the
> set of inherited operations is determined by those of the ancestor
> at the point where the private extension is declared.

Ahhh. I bet that's it. Does that mean that in the example above, Apple
will inherit *none* of Fruit's operations, since none of them were
declared before Apple?


--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Freezing question

[Tucker Taft]

Ted Dennison wrote:
> 
> In article <378E57FE.FA7EEB99@averstar.com>,
>   Tucker Taft <stt@averstar.com> wrote:
> > Ted Dennison wrote:
> 
> > >    type Fruit is abstract tagged private;
> > >    type Apple is abstract new Fruit with private;
> 
> > I suppose another problem is that, for a private extension, the
> > set of inherited operations is determined by those of the ancestor
> > at the point where the private extension is declared.
> 
> Ahhh. I bet that's it. Does that mean that in the example above, Apple
> will inherit *none* of Fruit's operations, since none of them were
> declared before Apple?

Correct.  See 7.3.1(7).

> --
> T.E.D.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Freezing question

[Ted Dennison]

In article <379347D8.A902583C@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Ted Dennison wrote:
> > Ahhh. I bet that's it. Does that mean that in the example above,
Apple
> > will inherit *none* of Fruit's operations, since none of them were
> > declared before Apple?
>
> Correct.  See 7.3.1(7).


Ahhh. OK. So then next question:
How would one implement a hierarchy where one object needs dispatching
operations that take a specific one of its chilren types as parameters?
I'm running out of ideas.

eg:

   type Widget is abstract tagged private;
   type Container is abstract new Widget with private;

   procedure Add
      (Child  : in out Widget;
       Parent : in out Container'Class
      );

Won't quite work because Add won't be inherited by any Containers unless
it is placed before the declaration of Container. But if I move it
between the two declarations, it won't compile because Container won't
have been declared yet.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Freezing question

[Robert I. Eachus]

Ted Dennison wrote:
 
> > > Ahhh. I bet that's it. Does that mean that in the example above, Apple
> > > will inherit *none* of Fruit's operations, since none of them were
> > > declared before Apple?
> >
> > Correct.  See 7.3.1(7).

   (Well, actually it will inherit any implicit operations created by
the declaration.  In this case it gets "=".)

> Ahhh. OK. So then next question:
> How would one implement a hierarchy where one object needs dispatching
> operations that take a specific one of its chilren types as parameters?
> I'm running out of ideas.

    The usual is either to declare a class wide operation, and dispatch
in the body or to define the operation over a wider scope than necessary
and raise an exception when necessary.
 
> eg:
> 
>    type Widget is abstract tagged private;
>    type Container is abstract new Widget with private;
> 
>    procedure Add
>       (Child  : in out Widget;
>        Parent : in out Container'Class
>       );
> 
> Won't quite work because Add won't be inherited by any Containers unless
> it is placed before the declaration of Container. But if I move it
> between the two declarations, it won't compile because Container won't
> have been declared yet.

    Semantically, having the class of the parent derived from the child
doesn't make sense in all cases anyway, so I would do the following:

    type Widget is abstract tagged private;
    procedure Add (Child  : in out Widget;
                   Parent : in out Widget'Class);
    type Container is abstract new Widget with private;

    ...
    procedure Add (Child  : in out Widget
                   Parent : in out Widget'Class) is
    begin
      if not Parent in Container'Class then raise ... end if;

    Of course, IMHO, you want Widget and Container to be related so that
Parent is actually a wider class than Widget, but that is another
issue...
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Freezing question

[Ted Dennison]

In article <37937E54.8D3AA9F0@mitre.org>,
  "Robert I. Eachus" <eachus@mitre.org> wrote:
>     The usual is either to declare a class wide operation, and
dispatch
> in the body or to define the operation over a wider scope than
necessary
> and raise an exception when necessary.
>     type Widget is abstract tagged private;
>     procedure Add (Child  : in out Widget;
>                    Parent : in out Widget'Class);
>     type Container is abstract new Widget with private;
>
>     ...
>     procedure Add (Child  : in out Widget
>                    Parent : in out Widget'Class) is
>     begin
>       if not Parent in Container'Class then raise ... end if;

That's pretty much what I ended up doing. The only difference is that I
had a "Container" operation to call, so I upcasted Parent to
"Container'Class". I should get a constraint_error if it isn't in
Container'Class.

>     Of course, IMHO, you want Widget and Container to be related so
that
> Parent is actually a wider class than Widget, but that is another
> issue...

I don't think so. There are operations that Containers need to perform
that don't make sense for all Widgets (eg: Adding a child widget to
manage). There are operations that all Widgets including containers need
to be able to perform (redrawing themselves). Containers are just a kind
of widget that has the extra capability of containing and managing other
widgets. But a Container should be able to contain a widget that is not
itself a container. %-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Dispatching with a child for a parameter? (was: Freezing question)

[Ted Dennison]

In article <379347D8.A902583C@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Ted Dennison wrote:
> > Ahhh. I bet that's it. Does that mean that in the example above,
Apple
> > will inherit *none* of Fruit's operations, since none of them were
> > declared before Apple?
>
> Correct.  See 7.3.1(7).


Ahhh. OK. So I'll ask the next question (with the topic appropriately
renamed:

How would one implement a hierarchy where one object has dispatching
operations that take a specific one of its chilren types as parameters?
I'm running out of ideas.

eg:

   type Widget is abstract tagged private;
   type Container is abstract new Widget with private;

   procedure Add
      (Child  : in out Widget;
       Parent : in out Container'Class
      );

Won't quite work because Add won't be inherited by any Containers unless
it is placed before the declaration of Container. But if I move it
between the two declarations, it won't compile because Container won't
have been declared yet.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.