Abstract realizations can't be inherited??

Abstract realizations can't be inherited??

[dennison]

I had a situation today where I wanted to declare a new tagged type which is
very similar to an existing one I had. Ahh, classic OO. I just derive it from
the existing type, and redefine the one operation that changed, right? Wrong!

The existing type's operations that I wanted to inherit are overrides of
abstract subprograms inherited from its parent type. The compiler blows up
and points to 3.9.3(6), which appears to say that I have to explicitly
override every abstract subprogram any "ancestor" type has. That means that
if a type is declared abstract, none of the "standard" operations you declare
for it can ever be inherited! What on earth is the logic behind that
restriction?

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Abstract realizations can't be inherited??

[Tucker Taft]

dennison@telepath.com wrote:

: I had a situation today where I wanted to declare a new tagged type which is
: very similar to an existing one I had. Ahh, classic OO. I just derive it from
: the existing type, and redefine the one operation that changed, right? Wrong!

: The existing type's operations that I wanted to inherit are overrides of
: abstract subprograms inherited from its parent type. The compiler blows up
: and points to 3.9.3(6), which appears to say that I have to explicitly
: override every abstract subprogram any "ancestor" type has. 
                                     ^^^
Not "any" ancestor, but rather *the* ancestor specified in the
definition of the type extension.  For a record extension, "the"
ancestor is the direct parent.  For a private extension, "the"
ancestor is the one named in the private extension declaration.

: ... That means that
: if a type is declared abstract, none of the "standard" operations you declare
: for it can ever be inherited! What on earth is the logic behind that
: restriction?

This is not the intent of 3.9.3(6).  It is only talking about the
type from which the subprograms are inherited.  For a record
extension, it is the direct parent.  For a private extension,
it is whatever ancestor is specified.

It would be helpful if you included the relevant source code.  It may
either be that there is a compiler bug, or that the description above 
lacks some critical detail.

: T.E.D.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Abstract realizations can't be inherited??

[dewar]

In article <6s491q$usm$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> I had a situation today where I wanted to declare a new tagged type which is
> very similar to an existing one I had. Ahh, classic OO. I just derive it from
> the existing type, and redefine the one operation that changed, right? Wrong!
>
> The existing type's operations that I wanted to inherit are overrides of
> abstract subprograms inherited from its parent type. The compiler blows up
> and points to 3.9.3(6), which appears to say that I have to explicitly
> override every abstract subprogram any "ancestor" type has. That means that
> if a type is declared abstract, none of the "standard" operations you declare
> for it can ever be inherited! What on earth is the logic behind that
> restriction?
>
> --
> T.E.D.

I suggest you post the code you are trying to compile. Obviously
you are doing something strange, but how can anyone guess what
if you don't post code. For example you might be trying to
derive a tagged type inside a procedure instead of inside a
package.

>
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Abstract realizations can't be inherited??

[dennison]

In article <EyDBJB.6JH.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> This is not the intent of 3.9.3(6).  It is only talking about the
> type from which the subprograms are inherited.  For a record
> extension, it is the direct parent.  For a private extension,
> it is whatever ancestor is specified.

Good. That's the way I'd expect it to work.

> It would be helpful if you included the relevant source code.  It may
> either be that there is a compiler bug, or that the description above
> lacks some critical detail.

I had to move on, so that code isn't around in that form any more. However, I
rigged up a dummy example, and I think I see my problem. ...My problem with
the code anyway :-).

package Thingamabob is
   type Instance is abstract tagged null record;

   procedure Foo (On : in out Instance) is abstract;

end Thingamabob;

package Thingamabob.Big is
   type Instance is new Thingamabob.Instance with private;

private
   procedure Foo (On : in out Instance);

   type Instance is new Thingamabob.Instance with null record;
end Thingamabob.Big;

with Thingamabob.Big;
package Big_And_Hairy_Thingamabob is
   type Instance is new Thingamabob.Big.Instance with private;

private

   type Instance is new Thingamabob.Big.Instance with null record;
end Big_And_Hairy_Thingamabob;

This gives me the error. But if I move the declartion of Thingamabob.Big.Foo
out of the private section, it works ok. So it looks like the real problem is
that I can't inherit a routine declared in the private section. That seems a
little more sensible.

The thing that makes that a little odd is that I can directly call
Thingamabob.Big.Foo, even though its declared in the private section. So for
the purposes of calling it isn't really "private", but for the purposes of
inheritance it is. %-(

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Abstract realizations can't be inherited??

[Tucker Taft]

dennison@telepath.com wrote:

: ...
: I had to move on, so that code isn't around in that form any more. However, I
: rigged up a dummy example, and I think I see my problem. ...My problem with
: the code anyway :-).

: package Thingamabob is
:    type Instance is abstract tagged null record;

:    procedure Foo (On : in out Instance) is abstract;

: end Thingamabob;

: package Thingamabob.Big is
:    type Instance is new Thingamabob.Instance with private;

: private
:    procedure Foo (On : in out Instance);

:    type Instance is new Thingamabob.Instance with null record;
: end Thingamabob.Big;

: with Thingamabob.Big;
: package Big_And_Hairy_Thingamabob is
:    type Instance is new Thingamabob.Big.Instance with private;

: private

:    type Instance is new Thingamabob.Big.Instance with null record;
: end Big_And_Hairy_Thingamabob;

: This gives me the error. But if I move the declartion of Thingamabob.Big.Foo
: out of the private section, it works ok. So it looks like the real problem is
: that I can't inherit a routine declared in the private section. That seems a
: little more sensible.

: The thing that makes that a little odd is that I can directly call
: Thingamabob.Big.Foo, even though its declared in the private section. So for
: the purposes of calling it isn't really "private", but for the purposes of
: inheritance it is. %-(

This sounds like a compiler bug.  If a type is non-abstract, then by
defintion all of its primitive procedures are non-abstract, even
if an overriding is done in the private part.

Time to file a bug report...

: --
: T.E.D.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Abstract realizations can't be inherited??

[dennison]

In article <EyGJID.858.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> This sounds like a compiler bug.  If a type is non-abstract, then by
> defintion all of its primitive procedures are non-abstract, even
> if an overriding is done in the private part.
>
> Time to file a bug report...

Awwww, again? :-)

I know I really should take Tucker's word for this, but I'd appreciate it if
someone would compile this example w/ a non-Aonix compiler and see if they get
an error. I'd hate to send in a bug report reading, "Tucker Taft says this is
wrong".

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Abstract realizations can't be inherited??

[Tucker Taft]

dennison@telepath.com wrote:
: In article <EyGJID.858.0.-s@inmet.camb.inmet.com>,
:   stt@houdini.camb.inmet.com (Tucker Taft) wrote:

: > This sounds like a compiler bug.  If a type is non-abstract, then by
: > defintion all of its primitive procedures are non-abstract, even
: > if an overriding is done in the private part.
: >
: > Time to file a bug report...

: Awwww, again? :-)

: I know I really should take Tucker's word for this, but I'd appreciate it if
: someone would compile this example w/ a non-Aonix compiler and see if they get
: an error. I'd hate to send in a bug report reading, "Tucker Taft says this is
: wrong".

Luckily, the response can also be "this bug has just been fixed by TT" ;-).

: --
: T.E.D.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Abstract realizations can't be inherited??

[dennison]

In article <EyK4AB.G5L.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> dennison@telepath.com wrote:
> : In article <EyGJID.858.0.-s@inmet.camb.inmet.com>,
> :   stt@houdini.camb.inmet.com (Tucker Taft) wrote:
>
> : > This sounds like a compiler bug.  If a type is non-abstract, then by
> : > defintion all of its primitive procedures are non-abstract, even
> : > if an overriding is done in the private part.
> : >
> : > Time to file a bug report...
> : I know I really should take Tucker's word for this, but I'd appreciate it if
> : someone would compile this example w/ a non-Aonix compiler and see if they
get
> : an error. I'd hate to send in a bug report reading, "Tucker Taft says this
is
> : wrong".
>
> Luckily, the response can also be "this bug has just been fixed by TT" ;-).
>

You were right. The tech-support guy was very sceptical until I mentioned your
name. Its like magic!

They also told me that if I had said "Robert Dewar" they would have been much
less helpful. I guess they're still a little ticked about having half their
customers call up and demand 80-bit floats :-).

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum