* Ambiguous reference - What is wrong with this? @ 2001-08-14 15:14 Marin David Condic 2001-08-14 16:56 ` Warren W. Gay VE3WWG ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Marin David Condic @ 2001-08-14 15:14 UTC (permalink / raw) O.K. I've got a compilation problem that is most likely due to my misunderstanding of some language rule. Below is some code that shows a simplified version of the problem. I'm using Gnat 3.13p on a WinNT PC. I'm pretty sure that the problem has something to do with the 'Class parameters creating some kind of ambiguity - but given that I've fully qualified the names, it seems like the compiler ought to know which procedure I meant to call. The quest6ion is twofold: Am I doing something illegal (if so, what?) and if it *is* illegal, then is there an alternate way of doing essentially the same thing? (One parameter being of a specific descendent and the other being a class-wide parameter. The class wide parameter wants to be an increasingly restrictive subset as you move down the chain of child packages) package Root is type Base is tagged private ; procedure Some_Proc ( Object : in out Base; Object2 : in out Base'Class) ; private type Base is tagged record Data_Item_1 : Natural := 0 ; end record ; end Root ; package body Root is procedure Some_Proc ( Object : in out Base; Object2 : in out Base'Class) is begin null ; end Some_Proc ; end Root ; package Root.Child1 is type Derive1 is new Base with private ; procedure Some_Proc ( Object : in out Derive1; Object2 : in out Derive1'Class) ; private type Derive1 is new Base with record Data_Item_2 : Natural := 0 ; end record ; end Root.Child1 ; package body Root.Child1 is procedure Some_Proc ( Object : in out Derive1; Object2 : in out Derive1'Class) is begin Root.Some_Proc ( Object => Root.Base (Object), Object2 => Object2) ; end Some_Proc ; end Root.Child1 ; package Root.Child1.Child2 is type Derive2 is new Derive1 with private ; procedure Some_Proc ( Object : in out Derive2; Object2 : in out Derive2'Class) ; private type Derive2 is new Derive1 with record Data_Item_3 : Natural := 0 ; end record ; end Root.Child1.Child2 ; package body Root.Child1.Child2 is procedure Some_Proc ( Object : in out Derive2; Object2 : in out Derive2'Class) is begin -- -- Dies here with the following error message: -- -- root-child1-child2.adb:15:20: ambiguous expression (cannot resolve "Some_Proc") -- root-child1-child2.adb:15:20: possible interpretation at root-child1.ads:4 -- root-child1-child2.adb:15:20: possible interpretation at root-child1.ads:3 -- gnatmake: "root-child1-child2.adb" compilation error -- Root.Child1.Some_Proc ( Object => Root.Child1.Derive1 (Object), Object2 => Object2) ; end Some_Proc ; end Root.Child1.Child2 ; Thanks for any help you can offer. 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-14 15:14 Ambiguous reference - What is wrong with this? Marin David Condic @ 2001-08-14 16:56 ` Warren W. Gay VE3WWG 2001-08-14 17:45 ` Warren W. Gay VE3WWG 2001-08-14 17:54 ` Marin David Condic 2001-08-14 17:44 ` Sergey Koshcheyev 2001-08-14 20:02 ` tmoran 2 siblings, 2 replies; 12+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-14 16:56 UTC (permalink / raw) Marin David Condic wrote: > > O.K. I've got a compilation problem that is most likely due to my > misunderstanding of some language rule. Below is some code that shows a > simplified version of the problem. I'm using Gnat 3.13p on a WinNT PC. I tried this out under HPUX 11.0, using gnat 3.12p, and got precisely the same results.. Your code looks to me like it should compile OK, and in fact I was expecting to use the same technique someday soon. But maybe my understanding of this situation is not complete. It seems that the compiler is confused between the Base object's Root.Some_Proc procedure, and the Root.Child1.Some_Proc, because of the message : root-child1-child2.adb:15:20: possible interpretation at root-child1.ads:3 which seems odd. Line 3 is singled out in the message where you derive the type from Base. This to me does not make sense, since all seems to be pretty clear about what the dispatch should be. I even made all of your tagged records non-private, and got the same results. I guess I can't help, or its a bug. Good luck, Warren. > I'm pretty sure that the problem has something to do with the 'Class > parameters creating some kind of ambiguity - but given that I've fully > qualified the names, it seems like the compiler ought to know which > procedure I meant to call. The quest6ion is twofold: Am I doing something > illegal (if so, what?) and if it *is* illegal, then is there an alternate > way of doing essentially the same thing? (One parameter being of a specific > descendent and the other being a class-wide parameter. The class wide > parameter wants to be an increasingly restrictive subset as you move down > the chain of child packages) > > package Root is > type Base is tagged private ; > procedure Some_Proc ( > Object : in out Base; > Object2 : in out Base'Class) ; > private > type Base is tagged record > Data_Item_1 : Natural := 0 ; > end record ; > end Root ; > > package body Root is > procedure Some_Proc ( > Object : in out Base; > Object2 : in out Base'Class) is > begin > null ; > end Some_Proc ; > end Root ; > > package Root.Child1 is > type Derive1 is new Base with private ; > procedure Some_Proc ( > Object : in out Derive1; > Object2 : in out Derive1'Class) ; > private > type Derive1 is new Base with record > Data_Item_2 : Natural := 0 ; > end record ; > end Root.Child1 ; > > package body Root.Child1 is > procedure Some_Proc ( > Object : in out Derive1; > Object2 : in out Derive1'Class) is > begin > Root.Some_Proc ( > Object => Root.Base (Object), > Object2 => Object2) ; > end Some_Proc ; > end Root.Child1 ; > > package Root.Child1.Child2 is > type Derive2 is new Derive1 with private ; > procedure Some_Proc ( > Object : in out Derive2; > Object2 : in out Derive2'Class) ; > private > type Derive2 is new Derive1 with record > Data_Item_3 : Natural := 0 ; > end record ; > end Root.Child1.Child2 ; > > package body Root.Child1.Child2 is > procedure Some_Proc ( > Object : in out Derive2; > Object2 : in out Derive2'Class) is > begin > -- > -- Dies here with the following error message: > -- > -- root-child1-child2.adb:15:20: ambiguous expression (cannot > resolve "Some_Proc") > -- root-child1-child2.adb:15:20: possible interpretation at > root-child1.ads:4 > -- root-child1-child2.adb:15:20: possible interpretation at > root-child1.ads:3 > -- gnatmake: "root-child1-child2.adb" compilation error > -- > Root.Child1.Some_Proc ( > Object => Root.Child1.Derive1 (Object), > Object2 => Object2) ; > end Some_Proc ; > end Root.Child1.Child2 ; > > Thanks for any help you can offer. > > 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/ -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-14 16:56 ` Warren W. Gay VE3WWG @ 2001-08-14 17:45 ` Warren W. Gay VE3WWG 2001-08-14 17:54 ` Marin David Condic 1 sibling, 0 replies; 12+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-14 17:45 UTC (permalink / raw) Replying further to this post with new information.. "Warren W. Gay VE3WWG" wrote: > > Marin David Condic wrote: > > > > O.K. I've got a compilation problem that is most likely due to my > > misunderstanding of some language rule. Below is some code that shows a > > simplified version of the problem. I'm using Gnat 3.13p on a WinNT PC. The AONIX compiler faults the same lines, with the message: ... LRM 8.6(31) Ambiguous call, possible definitions of Some_Proc appear at line 3 of root-child1.ads, line 4 (same file). I havn't had time to look at this in detail yet, but LRM 8.6 reports: 8.6 The Context of Overload Resolution (31) A complete context other than a pragma_argument_association shall not be ambiguous. I'd have to study this whole section to make sense of this error. Good luck, Warren. > > I'm pretty sure that the problem has something to do with the 'Class > > parameters creating some kind of ambiguity - but given that I've fully > > qualified the names, it seems like the compiler ought to know which > > procedure I meant to call. The quest6ion is twofold: Am I doing something > > illegal (if so, what?) and if it *is* illegal, then is there an alternate > > way of doing essentially the same thing? (One parameter being of a specific > > descendent and the other being a class-wide parameter. The class wide > > parameter wants to be an increasingly restrictive subset as you move down > > the chain of child packages) > > > > package Root is > > type Base is tagged private ; > > procedure Some_Proc ( > > Object : in out Base; > > Object2 : in out Base'Class) ; > > private > > type Base is tagged record > > Data_Item_1 : Natural := 0 ; > > end record ; > > end Root ; > > > > package body Root is > > procedure Some_Proc ( > > Object : in out Base; > > Object2 : in out Base'Class) is > > begin > > null ; > > end Some_Proc ; > > end Root ; > > > > package Root.Child1 is > > type Derive1 is new Base with private ; > > procedure Some_Proc ( > > Object : in out Derive1; > > Object2 : in out Derive1'Class) ; > > private > > type Derive1 is new Base with record > > Data_Item_2 : Natural := 0 ; > > end record ; > > end Root.Child1 ; > > > > package body Root.Child1 is > > procedure Some_Proc ( > > Object : in out Derive1; > > Object2 : in out Derive1'Class) is > > begin > > Root.Some_Proc ( > > Object => Root.Base (Object), > > Object2 => Object2) ; > > end Some_Proc ; > > end Root.Child1 ; > > > > package Root.Child1.Child2 is > > type Derive2 is new Derive1 with private ; > > procedure Some_Proc ( > > Object : in out Derive2; > > Object2 : in out Derive2'Class) ; > > private > > type Derive2 is new Derive1 with record > > Data_Item_3 : Natural := 0 ; > > end record ; > > end Root.Child1.Child2 ; > > > > package body Root.Child1.Child2 is > > procedure Some_Proc ( > > Object : in out Derive2; > > Object2 : in out Derive2'Class) is > > begin > > -- > > -- Dies here with the following error message: > > -- > > -- root-child1-child2.adb:15:20: ambiguous expression (cannot > > resolve "Some_Proc") > > -- root-child1-child2.adb:15:20: possible interpretation at > > root-child1.ads:4 > > -- root-child1-child2.adb:15:20: possible interpretation at > > root-child1.ads:3 > > -- gnatmake: "root-child1-child2.adb" compilation error > > -- > > Root.Child1.Some_Proc ( > > Object => Root.Child1.Derive1 (Object), > > Object2 => Object2) ; > > end Some_Proc ; > > end Root.Child1.Child2 ; > > > > Thanks for any help you can offer. > > > > 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/ > > -- > Warren W. Gay VE3WWG > http://members.home.net/ve3wwg -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-14 16:56 ` Warren W. Gay VE3WWG 2001-08-14 17:45 ` Warren W. Gay VE3WWG @ 2001-08-14 17:54 ` Marin David Condic 2001-08-14 19:24 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 12+ messages in thread From: Marin David Condic @ 2001-08-14 17:54 UTC (permalink / raw) Thanks for the test. At least that implies that it probably isn't a compiler bug. I think the compiler points at the type declaration because that is the point at which all the inherited operations enter into the picture. It unfortunately is not more specific - pointing to the exact procedures in the other packages that it is in conflict with - although one can easily guess. :-) The wierdness to me seems to be coming from the fact that I explicitly identified the procedure I wanted. Only probably because the names and the profiles are somehow considered identical and allowing for dispatching, maybe it means they aren't any different. Sort of a recursion that can't be terminated. The idea I was working on is to have some root class from which I start deriving. One branch of the tree evolves lists of various types while the other branch evolves data with various characteristics that are useful to have. What would happen is that I create a list type that can store anything derived from the root object (including another list), then evolve that to a list that can be sorted because the only objects that can get on it are derived from a child type requiring comparison operations (ordinal data). This eventually evolves to a list that can have statistics accumulated on it because the data items that can get on it must be derived from a child type that requires math operations (scalar data). And so on down the chain. In each case, you have a package with a specific list type and a 'Class wide element type because you need abstract types to describe ordinal and scalar data that hasn't been determined yet. (Deriving from the ordinal class you could have integer or string or enumerated data - so long as comparisons could be defined. Similarly from the scalar parent you could derive integer, real or even set or matrix data provided you could define appropriate math operators.) Maybe I could change the parameters to not be class-wide? But then, I'd have to have non-abstract parents for the ordinal or scalar data. Hmmmmmmmm...... Its a kind of experiment, so I'm not exactly married to the specific implementation. If you have an alternate scheme to try, I'm willing to take a shot at it. But I do think its important to this experiment that everything come from a single root type so all the descendent objects share some common properties and can be treated alike in some respects. (Heterogeneous lists, etc.) I'll entertain any ideas anyone has on this subject. Thanks. 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/ "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message news:3B795848.9DAFEE53@home.com... > > I tried this out under HPUX 11.0, using gnat 3.12p, and got precisely > the same results.. > > Your code looks to me like it should compile OK, and in fact I was expecting > to use the same technique someday soon. But maybe my understanding of this > situation is not complete. > > It seems that the compiler is confused between the Base > object's Root.Some_Proc procedure, and the Root.Child1.Some_Proc, > because of the message : > > root-child1-child2.adb:15:20: possible interpretation at root-child1.ads:3 > > which seems odd. Line 3 is singled out in the message where you > derive the type from Base. > > This to me does not make sense, since all seems to be pretty clear > about what the dispatch should be. I even made all of your tagged > records non-private, and got the same results. > > I guess I can't help, or its a bug. > > Good luck, Warren. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-14 17:54 ` Marin David Condic @ 2001-08-14 19:24 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 12+ messages in thread From: Warren W. Gay VE3WWG @ 2001-08-14 19:24 UTC (permalink / raw) Marin David Condic wrote: > Thanks for the test. At least that implies that it probably isn't a compiler > bug. > > I think the compiler points at the type declaration because that is the > point at which all the inherited operations enter into the picture. It > unfortunately is not more specific - pointing to the exact procedures in the > other packages that it is in conflict with - although one can easily guess. > :-) The wierdness to me seems to be coming from the fact that I explicitly > identified the procedure I wanted. Only probably because the names and the > profiles are somehow considered identical and allowing for dispatching, > maybe it means they aren't any different. Sort of a recursion that can't be > terminated. > > The idea I was working on is to have some root class from which I start > deriving. One branch of the tree evolves lists of various types while the > other branch evolves data with various characteristics that are useful to > have. ... Clearly, argument 2 (Object2) is ambiguous between the 2 calls. Then the remaining issue is the Root.Base object's dispatching on Object, which can dispatch to Root.Base.Some_Proc() or Root.Child1.Some_Proc() depending upon the argument given in arg1 (Object). I think the problem is related to Object2 of Root.Some_Proc : Even though dispatching says Object1 should only accept Derive1 here, the classwide argument Object2 says that Root.Some_Proc is a first candidate, in addition to Root.Child1.Some_Proc. :< Warren. > derived from the root object (including another list), then evolve that to a > list that can be sorted because the only objects that can get on it are > derived from a child type requiring comparison operations (ordinal data). > This eventually evolves to a list that can have statistics accumulated on it > because the data items that can get on it must be derived from a child type > that requires math operations (scalar data). And so on down the chain. In > each case, you have a package with a specific list type and a 'Class wide > element type because you need abstract types to describe ordinal and scalar > data that hasn't been determined yet. (Deriving from the ordinal class you > could have integer or string or enumerated data - so long as comparisons > could be defined. Similarly from the scalar parent you could derive integer, > real or even set or matrix data provided you could define appropriate math > operators.) > > Maybe I could change the parameters to not be class-wide? But then, I'd have > to have non-abstract parents for the ordinal or scalar data. Hmmmmmmmm...... > > Its a kind of experiment, so I'm not exactly married to the specific > implementation. If you have an alternate scheme to try, I'm willing to take > a shot at it. But I do think its important to this experiment that > everything come from a single root type so all the descendent objects share > some common properties and can be treated alike in some respects. > (Heterogeneous lists, etc.) I'll entertain any ideas anyone has on this > subject. Thanks. > > 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/ > > "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message > news:3B795848.9DAFEE53@home.com... > > > > I tried this out under HPUX 11.0, using gnat 3.12p, and got precisely > > the same results.. > > > > Your code looks to me like it should compile OK, and in fact I was > expecting > > to use the same technique someday soon. But maybe my understanding of this > > situation is not complete. > > > > It seems that the compiler is confused between the Base > > object's Root.Some_Proc procedure, and the Root.Child1.Some_Proc, > > because of the message : > > > > root-child1-child2.adb:15:20: possible interpretation at root-child1.ads:3 > > > > which seems odd. Line 3 is singled out in the message where you > > derive the type from Base. > > > > This to me does not make sense, since all seems to be pretty clear > > about what the dispatch should be. I even made all of your tagged > > records non-private, and got the same results. > > > > I guess I can't help, or its a bug. > > > > Good luck, Warren. > > -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-14 15:14 Ambiguous reference - What is wrong with this? Marin David Condic 2001-08-14 16:56 ` Warren W. Gay VE3WWG @ 2001-08-14 17:44 ` Sergey Koshcheyev 2001-08-14 20:10 ` Marin David Condic 2001-08-14 20:02 ` tmoran 2 siblings, 1 reply; 12+ messages in thread From: Sergey Koshcheyev @ 2001-08-14 17:44 UTC (permalink / raw) Hi! "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:9lbf8n$brf$1@nh.pace.co.uk... > O.K. I've got a compilation problem that is most likely due to my > misunderstanding of some language rule. Below is some code that shows a > simplified version of the problem. I'm using Gnat 3.13p on a WinNT PC. > > I'm pretty sure that the problem has something to do with the 'Class > parameters creating some kind of ambiguity - but given that I've fully > qualified the names, it seems like the compiler ought to know which > procedure I meant to call. The quest6ion is twofold: Am I doing something > illegal (if so, what?) and if it *is* illegal, then is there an alternate > way of doing essentially the same thing? (One parameter being of a specific > descendent and the other being a class-wide parameter. The class wide > parameter wants to be an increasingly restrictive subset as you move down > the chain of child packages) It looks to me that the problem is this: when you derive a type from some other type, the derived type gets the primitive operations of the parent. However, the dispatching parameter type (I'm not sure if it's the correct terminology) gets changed from the base type to the derived type. The parameter of type 'Class, on the other hand, remains untouched. What this leads to is this: when you declare Some_Proc for the Derive1 type, it does not override the Some_Proc of Base, but *overloads* it. This means that the type Derive1 has *two* primitive operations, and the type Derive2 has three. They are: procedure Some_Proc (Object : in out Derive2; Object2 : in out Base'Class); procedure Some_Proc (Object : in out Derive2; Object2 : in out Derive1'Class); procedure Some_Proc (Object : in out Derive2; Object2 : in out Derive2'Class); and these are the three operations that the compiler can't choose from. A way to overcome this problem would be to rename the Some_Proc you actually call to some other name. Qualifying the parameters, like Root.Child1.Some_Proc ( Object => Root.Child1.Derive1 (Object), Object2 => Root.Child1.Derive1'Class'(Object2)) ; (note the qualification of Object2) doesn't work. Sergey Koshcheyev ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-14 17:44 ` Sergey Koshcheyev @ 2001-08-14 20:10 ` Marin David Condic 2001-08-15 7:38 ` Sergey Koshcheyev 0 siblings, 1 reply; 12+ messages in thread From: Marin David Condic @ 2001-08-14 20:10 UTC (permalink / raw) Hmmmmmm........ I *think* I understand. This may take a bit of pondering. 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. I'll have to cogitate on this - but it appears I may not be able to get there from here. If I'm creating overloadings and qualifying the overloadings isn't disambiguating them, then it seems the only answer is to create new names. However doing so means the child class a couple of layers 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 'Class qualification, I may avoid the ambiguity, but may not be able to preserve the subsets I want to have. Hmmmmmmm............ 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:9lbo1h$2bhq$1@ns.felk.cvut.cz... > > It looks to me that the problem is this: when you derive a type from some > other type, the derived type gets the primitive operations of the parent. > However, the dispatching parameter type (I'm not sure if it's the correct > terminology) gets changed from the base type to the derived type. The > parameter of type 'Class, on the other hand, remains untouched. > What this leads to is this: when you declare Some_Proc for the Derive1 type, > it does not override the Some_Proc of Base, but *overloads* it. This means > that the type Derive1 has *two* primitive operations, and the type Derive2 > has three. They are: > > procedure Some_Proc > (Object : in out Derive2; > Object2 : in out Base'Class); > procedure Some_Proc > (Object : in out Derive2; > Object2 : in out Derive1'Class); > procedure Some_Proc > (Object : in out Derive2; > Object2 : in out Derive2'Class); > > and these are the three operations that the compiler can't choose from. A > way to overcome this problem would be to rename the Some_Proc you actually > call to some other name. Qualifying the parameters, like > Root.Child1.Some_Proc ( > Object => Root.Child1.Derive1 (Object), > Object2 => Root.Child1.Derive1'Class'(Object2)) ; > (note the qualification of Object2) doesn't work. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-14 20:10 ` Marin David Condic @ 2001-08-15 7:38 ` Sergey Koshcheyev 2001-08-15 13:49 ` Marin David Condic 0 siblings, 1 reply; 12+ messages in thread From: Sergey Koshcheyev @ 2001-08-15 7:38 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-15 7:38 ` Sergey Koshcheyev @ 2001-08-15 13:49 ` Marin David Condic 0 siblings, 0 replies; 12+ messages in thread From: Marin David Condic @ 2001-08-15 13:49 UTC (permalink / raw) 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. > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-14 15:14 Ambiguous reference - What is wrong with this? Marin David Condic 2001-08-14 16:56 ` Warren W. Gay VE3WWG 2001-08-14 17:44 ` Sergey Koshcheyev @ 2001-08-14 20:02 ` tmoran 2001-08-15 6:17 ` Simon Wright 2 siblings, 1 reply; 12+ messages in thread From: tmoran @ 2001-08-14 20:02 UTC (permalink / raw) I think the problem occurs back at package Root.Child1 is type Derive1 is new Base with private ; inherits procedure Some_Proc ( Object : in out Derive1; -- was Base Object2 : in out Base'Class) ; and then you declare another procedure, with a different second parameter, procedure Some_Proc ( Object : in out Derive1; Object2 : in out Derive1'Class) ; now which is Root.Child1.Some_Proc ( Object => Root.Child1.Derive1 (Object), Object2 => Object2) ; -- in Derive1'Class and Base'Class supposed to be calling? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-14 20:02 ` tmoran @ 2001-08-15 6:17 ` Simon Wright 2001-08-17 16:34 ` Marin David Condic 0 siblings, 1 reply; 12+ messages in thread From: Simon Wright @ 2001-08-15 6:17 UTC (permalink / raw) tmoran@acm.org writes: > I think the problem occurs back at > package Root.Child1 is > type Derive1 is new Base with private ; > inherits > procedure Some_Proc ( > Object : in out Derive1; -- was Base > Object2 : in out Base'Class) ; > and then you declare another procedure, with a different second parameter, > procedure Some_Proc ( > Object : in out Derive1; > Object2 : in out Derive1'Class) ; > now which is > Root.Child1.Some_Proc ( > Object => Root.Child1.Derive1 (Object), > Object2 => Object2) ; -- in Derive1'Class and Base'Class > supposed to be calling? Root.Child1.Some_Proc ( Object => Root.Child1.Derive1 (Object), Object2 => Root.Base'Class (Object2)) ; compiles OK (GNAT 3.14a) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ambiguous reference - What is wrong with this? 2001-08-15 6:17 ` Simon Wright @ 2001-08-17 16:34 ` Marin David Condic 0 siblings, 0 replies; 12+ messages in thread From: Marin David Condic @ 2001-08-17 16:34 UTC (permalink / raw) I just tried this with Gnat 3.13p and it seemed to work The question in my mind is will it do the thing I want it to do? I convert Object2 back to the base type & presumably everything is fine if the lower level Some_Proc wants to dynamically allocate something that matches. But have I prevented something from entering that isn't of the more specific Derive1 type? If converting back to the Base type finds a matching procedure, couldn't something that is not of Derive1 type enter the Some_Proc? In other words, if I'm using this to restrict some child type list from having data values put into it that don't match some more complex derived child class, am I not just circumventing that check? 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/ "Simon Wright" <simon@pushface.org> wrote in message news:x7v1ymdyhi0.fsf@smaug.pushface.org... > tmoran@acm.org writes: > > Root.Child1.Some_Proc ( > Object => Root.Child1.Derive1 (Object), > Object2 => Root.Base'Class (Object2)) ; > > compiles OK (GNAT 3.14a) ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2001-08-17 16:34 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-08-14 15:14 Ambiguous reference - What is wrong with this? Marin David Condic 2001-08-14 16:56 ` Warren W. Gay VE3WWG 2001-08-14 17:45 ` Warren W. Gay VE3WWG 2001-08-14 17:54 ` Marin David Condic 2001-08-14 19:24 ` Warren W. Gay VE3WWG 2001-08-14 17:44 ` Sergey Koshcheyev 2001-08-14 20:10 ` Marin David Condic 2001-08-15 7:38 ` Sergey Koshcheyev 2001-08-15 13:49 ` Marin David Condic 2001-08-14 20:02 ` tmoran 2001-08-15 6:17 ` Simon Wright 2001-08-17 16:34 ` Marin David Condic
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox