Re: [api-dev] multiple-inheritance interafces and method name clashes

[Rony G. Flatscher]

Your message dated "2005-10-19 09:27 AM" just appeared in my inbox ("2005-10-21"), almost two days late! Something seems to be wrong with dispatching the messages via the OOo listserver. Therefore it is very hard to communicate in a timely manner at the moment, so therefore I just would like to comment in a more general term. Originally, I had thought of something like:     o~m1~XFoo~bar or maybe:     o~m1.XFoo~bar [this way being able to unambiguously resolve the interface by choosing resp. qualifying its name with the module-name making it distinguishable from m2.XFoo] You are thus stuck with the same fragility problem as OOo Basic and PyUNO:  As in general you cannot know statically whether a given object (referenced by o) only implements one m_a1...m_ak.XFoo in one module (m_a1...m_ak) or multiple m_a1...m_ak.XFoo, ...,  m_z1...m_zl.XFoo in different modules, the notation   o~XFoo~bar can become ambiguous at runtime. but became unsure, hence my request for a Java example. In that Java example I assumed (probably falsely) that object "o" possesses the XFoo interface from m1 (but not from m2) by the name "XFoo", which then can be easily addressed by ooRexx (as there would not be a reason to distinguis between the two). Not sure what you want to say.  In Java, m1.XFoo and m2.XFoo denote Java interface types, and any (otherwise ambiguous) use of simply "XFoo" in the program text is disambiguated at compile time throught the use of import declarations.  This is completely different from ooRexx (if I understand it correctly), where the "XFoo" in o~XFoo~bar is the name of a method; that name is chosen systematically (if there is a UNO interface named m_1...m_k.XFoo, name the method XFoo), but in a way that name clashes can occur (if there are two UNO interfaces named m_a1...m_ak.XFoo and m_b1...m_bl.XFoo). The point I wanted to make is as follows: if XFoo is implemented in two different modules then it should be possible to denote the module from which you want to draw XFoo, in Java you do it by using the class object that represents the appropriate XFoo by supplying the fully qualified name to it (ie. the module name), in ooRexx you can therefore apply the same logic, ie. use the appropriate Java class object. If the runtime support for any language has to "guess", and if there are no rules (like order governs which XFoo to pick), then one is really lost. In such cases it becomes mandatory to fully qualify the XFoo which seems to be possible in Basic and Python. The question for me still is: should ooRexx allow for the Basic and Python behaviour which does try to pick the interface at runtime on its own by default. Or should it always demand from the programmer to denote the interface from which to draw methods or in which to refer to attributes? Regards ---rony