Rony G. Flatscher wrote:
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.
Yes, all the OOo mailing lists were extremely slow the last few days.
Hopefully it gets better now!
(See below for content...)
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?
Hard to say, as there are two conflicting goals here: On the one hand,
what you need to write down for a method call should in general be short
(so that your language binding is easily usable). On the other hand,
what UNO method (of what UNO interface) a method call as written down
denotes should be clear statically (to avoid the discussed fragility
issues). An easy solution for the second goal is to always use very
long method names (com_sun_star_uno_...), which obviously violates the
first goal. So, the best for you would be to come up with some clever
solution that meets both goals. :)
-Stephan
Regards
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
