Re: Ambiguous reference - What is wrong with this?

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

O.K. I think I've got it. At the first level of derivation, I've rather
implicitly created a Derive1/Base'Class procedure which looks essentially
the same as a Derive1/Derive1'Class procedure because, after all, a
Derive1'Class is also a Base'Class. The attempt to resolve it doesn't work
because there are, in effect, two procedures in the package spec - one that
I visibly created and one that is automagically created. So basically, I can
get away with this if I only go to one level of derivation, but the next
level up is going to see duplicate procedures below it.

Well, I'll need to ponder this for a while & see what alternative approaches
I might take. Generics suggest one possible answer, but I don't find it as
clean as an abstract tagged type for bringing in lots of user defined
functions. Whatever happens, I think I'm in a position where I have to do
some major restructuring of what I've got so far. Bummer, dude! :-(

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Sergey Koshcheyev" <serko84@hotmail.com> wrote in message
news:9ld8su$eak$1@ns.felk.cvut.cz...
>
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9lc0jf$hod$1@nh.pace.co.uk...
> > Hmmmmmm........ I *think* I understand. This may take a bit of
pondering.
>
> Well, I should have explained that better, let me try it once more :-)
> The problem is that you're overloading instead of overriding. And the
> problem occurs because when Some_Proc is inherited for type Derive1, it
> turns from
> procedure Some_Proc
>   (Object  : in out Base;
>    Object2 : in out Base'Class);
> to
> procedure Some_Proc
>   (Object  : in out Derive1;
>    Object2 : in out Base'Class);
> (note that the type of the Object2 parameter doesn't change)
> so the Some_Proc you define doesn't override it.
>
> > In any event, it isn't clear how I get out of it considering thatI'd
kind
> of
> > like to keep the second parameter a 'Class wide type.
>
> Ada is not covariant, so I'm quite sure an approach using tagged types for
> both the containers and the  elements (in the context of your problem)
won't
> work.
>
> > <snip>
> > down can't hide some operation of one of its parents. I'd like to be
able
> to
> > say my list can only accept elements of some subclass and increasingly
> > restrict that subclass (see other posts in this thread.) By removing the
>
> I think that having the root list package generic and adding new generic
> parameters to child packages (and thus adding requirements for the stored
> type) might work, but I haven't tested it and I don't know if it will be
> appropriate for the problem you're solving. I can provide an example of
what
> I have in mind, if needed.
>
> Sergey.
>
>