preventing inheritance

preventing inheritance

[Tom Moran]

Given
type T is tagged ...
procedure A(X:T)
function  B(X:T) return ...
procedure C(X:T)
  and
Type U is new T with ...
procedure D(X:T)
procedure E(X:T)
function  F(X:T) return ...

  BUT
B(X:U) is, for reasons beyond my control, illegal.

  What is the best way to prevent/catch B(X:U)?

Currently I replace the inherited B(X:U) with
function  B(X:U) return ... is
begin
  raise this_is_a_no_no;
  return 0; -- all functions need at least one return
end B;

Re: preventing inheritance

[Norman H. Cohen]

Tom Moran wrote:
 
> Given
> type T is tagged ...
> procedure A(X:T)
> function  B(X:T) return ...
> procedure C(X:T)
>   and
> Type U is new T with ...
> procedure D(X:T)
> procedure E(X:T)
> function  F(X:T) return ...
> 
>   BUT
> B(X:U) is, for reasons beyond my control, illegal.
> 
>   What is the best way to prevent/catch B(X:U)?
> 
> Currently I replace the inherited B(X:U) with
> function  B(X:U) return ... is
> begin
>   raise this_is_a_no_no;
>   return 0; -- all functions need at least one return
> end B;

Apparently, when you say that B(X:U) is "illegal", what you mean is that
B is an operation that, for reasons having to do with your application,
does not have a sensible interpretation for objects of type U.

In this case, your inheritance hierarchy is inappropriate, since it
violates the "is-a" rule.  Since U is derived from T, it should be the
case that a U "is a" special kind of T, and therefore that anything that
can be done with a T (e.g. applying operation B to it) should also be
doable to a U.

Quite properly, Ada does not provide a way to prevent inheritance of an
operation from a parent tagged type.

What you should do is reorganize your hierarchy.  For example, you might
create a new abstract root type, say S, whose operations are the
operations common to both your original T and your original U, then
derive both T and U from S:

 type S is abstract tagged ...
 procedure A(X:S)
 procedure C(X:S)

 type T is new S with ...
  -- inherits A(X:T) and C(X:T)
 function  B(X:T) return ...

 type U is new S with ...
 -- inherits A(X:U) and C(X:U)
 procedure D(X:U)
 procedure E(X:U)
 function  F(X:U) return ...

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: preventing inheritance

[Tom Moran]

>Create abstract S and derive T and U from it
  I could do this but it will look rather bizarre.  Type T is an 
MS Windows Edit control and type U is a multiline Edit control. 
Operation B is 'get first visible character horizontally' for the
single line edit control, but the corresponding multiline operation 
is to get the first visible line vertically.  Other than that, it's
always reasonable to have one operation which either is identical for
single/multiline edit boxes, and thus can be inherited, or two
operations which have obviously analogous, if not identical,
interpretations, and thus need over-riding.
   Several ways of getting around this annoyance have been suggested,
but none seems likely to cause a user to look and say 'obviously, that's
the only reasonable organization'.

Re: preventing inheritance

[Tom Moran]

The real problem is that U really 'is a' T, it's just that MS does not
give a way to implement a particular operation on objects of type U.
It is not satisfying to simply say 'well, I guess U's aren't T's after
all'.

Re: preventing inheritance

[Larry Kilgallen]

In article <32B64298.3CC5@bix.com>, Tom Moran <tmoran@bix.com> writes:
> The real problem is that U really 'is a' T, it's just that MS does not
> give a way to implement a particular operation on objects of type U.
> It is not satisfying to simply say 'well, I guess U's aren't T's after
> all'.

Inheritance capabilities in a language provide compiler enforcement
of an orderly set of relationships.  We tend to value them because
they detect cases where the set of relationships we had in mind is
not orderly.  Unfortunately they also detect cases where the lack
of orderliness originated outside our sphere of influence.

Larry Kilgallen

Re: preventing inheritance

[Norman H. Cohen]

Tom Moran wrote:
> 
> The real problem is that U really 'is a' T, it's just that MS does not
> give a way to implement a particular operation on objects of type U.
> It is not satisfying to simply say 'well, I guess U's aren't T's after
> all'.

A simple tautology:

 - A multiline edit control is an edit control.

 - A multiline edit control does not have a Get_First_Character
operation.

 - Therefore there exist edit controls that do not have
Get_First_Character operations.

In other words, Get_First_Character should not be an operation of edit
controls.

My original suggestion--

   package Edit_Controls is
      type Edit_Control_Type is abstract tagged private;
      -- various operations common to all edit controls
      ...
   end Edit_Controls;

   package Edit_Controls.Single_Line is
      type Single_Line_Edit_Control_Type is 
         new Edit_Control_Type with private;
      procedure Get_First_Character
         (Control : in out Single_Line_Edit_Control_Type;
          Item    : out Character);
   private
      type Single_Line_Edit_Control_Type is
         new Edit_Control_Type with null record;
   end Edit_Controls.Single_Line;

   package Edit_Controls.Multiline is
      type Multiline_Edit_Control_Type is 
         new Edit_Control_Type with private;
      ...
   end Edit_Controls.Multiline;

--still strikes me as a perfectly natural way to model this problem
domain.  Why do you think this looks "bizarre"?

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: preventing inheritance

[Tom Moran]

> --still strikes me as a perfectly natural way to model this problem
> domain.  Why do you think this looks "bizarre"?
  It looks eminently reasonable from a design perspective, and indeed,
I'll probably change the existing code to that approach.  But I think it
looks 'bizarre' from the perspective of a user because:
1) Of the two dozen operations on Edit_Control, this is the _only_ one
that doesn't also work on Multiline_Edit_Control.  It seems that a
significant structural change is required by something small and obscure
enough to almost call a bug.  Indeed, an informal application view of
the objects Multiline_Edit_Control and Edit_Control would say the one
"is a" the other - with a glitch.  I'm tempted to simply have a 
  procedure Get_First_Character
          (Control : in out Multi_Line_Edit_Control_Type; ...
that raises "Not_Yet_Implemented"- except that defers error detection to
run time.
2) If MS in the future adds a way to implement Get_First_Character on
Multiline edit controls, it would become reasonable to move that routine
from Edit_Controls.Single_Line to Edit_Controls, leaving
Edit_Controls.Single_Line a bodyless package containing nothing but a
single type definition.  It would become yet another instance of "this
seemingly pointless complexity is here for historical reasons". 
  My difficulty is really an aesthetic one so perhaps the only solution
is to modify my aesthetic sensibilities. ;)

Re: preventing inheritance

[Robert I. Eachus]

In article <32B85141.376A@bix.com> Tom Moran <tmoran@bix.com> writes:

  > 2) If MS in the future adds a way to implement Get_First_Character on
  > Multiline edit controls, it would become reasonable to move that routine
  > from Edit_Controls.Single_Line to Edit_Controls, leaving
  > Edit_Controls.Single_Line a bodyless package containing nothing but a
  > single type definition.  It would become yet another instance of "this
  > seemingly pointless complexity is here for historical reasons". 
  >   My difficulty is really an aesthetic one so perhaps the only solution
  > is to modify my aesthetic sensibilities. ;)

   There are two other solutions:

   1) Provide your own Get_First_Character for multiline edits.  Can
be done.

   2) Define Get_First_Character outside of Edit_Controls, or nested
in a Single_Line package.  This reflects the actual structure--an
operation on the parent that is not inherited.


--

					Robert I. Eachus

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