Overlaying of methods.

Overlaying of methods.

[Stefan Muehlebach]

Hello.
I have a problem with objects and inherited methods. I have two classes,
declared in two seperated packages, on inherited from the other. Both
declare their own 'Init' procedures.

Part of the first package:

  type XaCrowColumn     is new XaContainer with private;
  type XaCrowColumn_Ptr is access all XaCrowColumn'class;
  procedure Init(o           : access XaCrowColumn;
                 parent      : access XaApplication'class;
                 orientation : ...;
                 num_cols    : Integer := 1;
                 adjust_last : Boolean := True);

(XaApplication is the parent class for all classes in my library)

Part of the second package (which uses the one above):

  type XaCradioBox     is new XaCrowColumn with private;
  type XaCradioBox_Ptr is access all XaCradioBox'class;
  procedure Init(o           : access XaCradioBox;
                 parent      : access XaApplication'class;
                 orientation : ...;
                 num_cols    : Integer := 1);

In the main program I declare a new object the following way:

  myRadioBox: XaCradioBox_Ptr := new XaCradioBox;

BUT - and that is the frustrating point - if I write a statement like
this

  Init(myRadioBox, aParent, anOrientation);

not the method in the second package is called but the one in the first!
Although the first parameter is of type XaCradioBox. Why?
I found out, that if I remove the defaults or write the same parameter
list for both 'Init'-procedures every thing is ok.

The question is also in which way does Ada look for an appropriate
method.

If someone could help me or at least verify my problem I would be very
happy.

Re: Overlaying of methods.

[Jon S Anthony]

In article <34310F93.41C6@htl-bw.ch> Stefan Muehlebach <ia94mueh@htl-bw.ch> writes:

>   type XaCrowColumn     is new XaContainer with private;
>   type XaCrowColumn_Ptr is access all XaCrowColumn'class;
>   procedure Init(o           : access XaCrowColumn;
>                  parent      : access XaApplication'class;
>                  orientation : ...;
>                  num_cols    : Integer := 1;
>                  adjust_last : Boolean := True);
> 
> (XaApplication is the parent class for all classes in my library)
> 
> Part of the second package (which uses the one above):
> 
>   type XaCradioBox     is new XaCrowColumn with private;
>   type XaCradioBox_Ptr is access all XaCradioBox'class;
>   procedure Init(o           : access XaCradioBox;
>                  parent      : access XaApplication'class;
>                  orientation : ...;
>                  num_cols    : Integer := 1);
> 
> In the main program I declare a new object the following way:
> 
>   myRadioBox: XaCradioBox_Ptr := new XaCradioBox;
> 
> BUT - and that is the frustrating point - if I write a statement like
> this
> 
>   Init(myRadioBox, aParent, anOrientation);

type XaCradioBox has two overloaded Init procedures (3.2.3 & 3.4): the
one inherited from it's parent with the "adjust_last" in its signature
(implicitly declared) and the one explicitly declared on it without
"adjust_last" in its signature.  Either of these can be invoked on
myRadioBox.  Perhaps more to the point, either of these can be chosen
to determine the runtime dispatch resolution.  Which of these is
chosen for this is a compile time overload resolution.

Off the top of my head, the call looks like it should give a compile
time ambiguous overload resolution error.  If this isn't true, could
Robert, Bob or Tucker explain why it is OK?

/Jon
-- 
Jon Anthony
STL, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Overlaying of methods.

[Stefan Muehlebach]

Jon S Anthony wrote:
> 
> type XaCradioBox has two overloaded Init procedures (3.2.3 & 3.4): the
> one inherited from it's parent with the "adjust_last" in its signature
> (implicitly declared) and the one explicitly declared on it without
> "adjust_last" in its signature.  Either of these can be invoked on
> myRadioBox.  Perhaps more to the point, either of these can be chosen
> to determine the runtime dispatch resolution.  Which of these is
> chosen for this is a compile time overload resolution.
> 
> Off the top of my head, the call looks like it should give a compile
> time ambiguous overload resolution error.  If this isn't true, could
> Robert, Bob or Tucker explain why it is OK?
> 
> /Jon
> --
> Jon Anthony
> STL, Belmont, MA 02178, 617.484.3383
> "Nightmares - Ha!  The way my life's been going lately,
>  Who'd notice?"  -- Londo Mollari

I have to add some more infos about my problem.
I use the GNAT-Compiler 3.09 and the program can be compiled WITHOUT any
error or warning messages.

It is impossible to use the Init procedure declared for XaCradioBox even
if I use the fully qualified call like this:

  Main_Pack.RowColumn_Pack.RadioBox_Pack.Init(...);

It's funny that the problem can be solved by removing the 'adjust_last'
parameter from the first specification.

Re: Overlaying of methods.

[Jon S Anthony]

In article <34325DCC.167E@htl-bw.ch> Stefan Muehlebach <ia94mueh@htl-bw.ch> writes:

> > Off the top of my head, the call looks like it should give a compile
> > time ambiguous overload resolution error.  If this isn't true, could
> > Robert, Bob or Tucker explain why it is OK?
> > 
> > /Jon
> > --
> > Jon Anthony
> > STL, Belmont, MA 02178, 617.484.3383
> > "Nightmares - Ha!  The way my life's been going lately,
> >  Who'd notice?"  -- Londo Mollari
> 
> I have to add some more infos about my problem.
> I use the GNAT-Compiler 3.09 and the program can be compiled WITHOUT any
> error or warning messages.

I tried an example and can confirm that GNAT 3.09 on sparc.solaris
does behave as the poster says with this sort of example.  Looks like
a bug in GNAT.  Maybe it is fixed in 3.10??

> 
> It is impossible to use the Init procedure declared for XaCradioBox even
> if I use the fully qualified call like this:
> 
>   Main_Pack.RowColumn_Pack.RadioBox_Pack.Init(...);

That's because there are _two_ such Init's in this package: the
implicitly declared inherited op and the explicit one.  Read 3.4
(17&18) closely.

> It's funny that the problem can be solved by removing the 'adjust_last'
> parameter from the first specification.

That's completely expected, as that would remove the second
interpretation for Init...

/Jon

-- 
Jon Anthony
STL, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Overlaying of methods.

[Tucker Taft]

Jon S Anthony (jsa@alexandria.organon.com) wrote:
: In article <34325DCC.167E@htl-bw.ch> Stefan Muehlebach 
: <ia94mueh@htl-bw.ch> writes:

: > > Off the top of my head, the call looks like it should give a compile
: > > time ambiguous overload resolution error.  If this isn't true, could
: > > Robert, Bob or Tucker explain why it is OK?
: > > 
: > > /Jon
: > > --
: > > Jon Anthony
: > > STL, Belmont, MA 02178, 617.484.3383
: > > "Nightmares - Ha!  The way my life's been going lately,
: > >  Who'd notice?"  -- Londo Mollari
: > 
: > I have to add some more infos about my problem.
: > I use the GNAT-Compiler 3.09 and the program can be compiled WITHOUT any
: > error or warning messages.

: I tried an example and can confirm that GNAT 3.09 on sparc.solaris
: does behave as the poster says with this sort of example.  Looks like
: a bug in GNAT.  Maybe it is fixed in 3.10??

It does sound like a bug.  Our front end gives the following error message:

   33   Init(myRadioBox, aParent, anOrientation);
        *
*****Error: LRM:8.6(31) Ambiguous call, possible definitions of Init appear at
*****        line 20 of file ambig_init.ada, line 8 (same file).

: Jon Anthony
: STL, Belmont, MA 02178, 617.484.3383 
: "Nightmares - Ha!  The way my life's been going lately,
:  Who'd notice?"  -- Londo Mollari

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

Re: Overlaying of methods.

[Robert A Duff]

In article <JSA.97Sep30175102@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>Off the top of my head, the call looks like it should give a compile
>time ambiguous overload resolution error.  If this isn't true, could
>Robert, Bob or Tucker explain why it is OK?

Maybe Init is being called from a place where only one of the two Init's
is visible?  I'd have to see the complete code to be sure what's going
on here.

- Bob

Re: Overlaying of methods.

[Tom Moran]

I tried your problem with two different compilers and both pointed out
that the call on Init was ambiguous.

Re: Overlaying of methods.

[Stefan Muehlebach]

Tom Moran wrote:
> 
> I tried your problem with two different compilers and both pointed out
> that the call on Init was ambiguous.

But what in this example is abmiguous? I thought that in an object
oriented language like Ada9x every object has a 'tag' whitch determines
its type.
If I declare an Object of Type 'XaCradioBox' and there IS a procedure
'Init' for this Type I expect that this procedure is choosen and not the
one from its parent.

Re: Overlaying of methods.

[Robert A Duff]

In article <34325DA2.41C6@htl-bw.ch>,
Stefan Muehlebach  <ia94mueh@htl-bw.ch> wrote:
>But what in this example is abmiguous? ...

I think what's confusing you is that you think that the Init operation
is overriding the one that is inherited from the parent type.  That's
not the case in your example, because the two Init's do not have
type-conformant parameter profiles.  So, your type ends up with *two*
things called Init -- one inherited from the parent type, plus a new
one.  If they're visible, then calls will tend to be ambiguous, because
of all the defaults you have.

On the other hand, if you're dispatching via the parent types operation,
that operation will get called, since it is not overridden.

It's hard to understand what's going on without the complete sources --
from what you posted, we can't tell what's visible at the point of the
call to Init.

If what you're trying to do is override the parent's Init procedure,
then just make sure the number and types of parameters (and results, if
any) match.  And parameter modes and subtypes.  (But parameter names and
defaults don't have to match.)

- Bob

Re: Overlaying of methods.

[Stefan M=?iso-8859-1?Q?=FChlebach]

Hi Robert

Thank you very much for your help.
It is true that if both 'Init'-procedures has the same parameter 
profile every thing is allright. And in this case it was very easy 
to redesign the procedures to have the same parameter profile.

But I'm still asking me why an explicit call 
(Pack1.Pack2.Pack3.Init(...)) doesn't work.

The sources are part of a class library for Motif programming. I'm 
not the designer - I just trying to make it run at least... :-(

I noticed that the one who wrote the original files made this 
mistake (trying to override a parent procedure by a child procedure 
with a different parameter profile) almost in every package.

-Stefan

Re: Overlaying of methods.

[Jon S Anthony]

In article <343967BA.598C@htl-bw.ch> Stefan M=?iso-8859-1?Q?=FChlebach <ia94mueh@htl-bw.ch>?= writes:

> But I'm still asking me why an explicit call 
> (Pack1.Pack2.Pack3.Init(...)) doesn't work.

For the exact same reason: there are two such Inits in Pack3, the
implicit inherited one and the explicitly declared one.

/Jon
-- 
Jon Anthony
STL, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Overlaying of methods.

[Tom Moran]

Would the parent Init be legal?  Yes.  Is the child Init legal? Yes.
Which did the programmer mean?  That is ambiguous.  Now if you want to
add a rule that says "resolve ambiguity by using the child, not the
parent", that's a reasonable idea, but it's not an Ada 95 rule.