Rony G. Flatscher wrote:
... cut ...
Just curious: how do you write down in ooRexx calls to method bar
on an object that implements the two interfaces
module m1 { interface XFoo { void bar(); }; };
module m2 { interface XFoo { void baz(); }; };
Hmm, good question.
Could you please hint how you would do that in Java (pseudo-code
suffices, ie. without casting)? Reason being, that whatever can be
done via Java can be done in ooRexx (using a very relaxed, almost
pseudo-code like syntax).
In Java:
import m1.XFoo; // the key to using short, unambiguous XFoo
later on
...
Object o = ...;
XFoo foo = (XFoo) UnoRuntime.queryInterface(XFoo.class, o);
foo.bar();
Oh, o.k., then this is how you would do it in ooRexx:
o~XFoo~bar
The point I tried to make is that in
o~XFoo~bar
XFoo is ambiguous (it could denote either m1.XFoo or m2.XFoo), and I
was wondering how you solve that.
Well, as ooRexx uses Java (instead of C++) for the bridging, the
solution would be the same as for Java. Or could object o have two
different interfaces by the same name? If so, then it would be possible
to explicitly query the interface supplying the class object for the
respective interface, like you show in your example (except, I would
then explicitly use m1.XFoo.class and m2.XFoo.class in queryInterface()
instead)..
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).
If both interfaces could be present in o, then you need to qualify it
with so many names as to make it unambiguously clear, which XFoo one
wants to use (one possibility in ooRexx could then be o~m1.XFoo~bar,
although it is not implemented that way in the present beta, but could
be added, if that problem really can pop-up).
---rony
P.S.: It still looks a little bit strange to me that the module name m1
resp. m2 would not be used for uniquely identifying which XFoo you would
like to address.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
