(Hmm, strange, just now I have been receiving the e-mails you have sent
this morning, hence the late answers/remarks.)
your approach is not so different than the other one implemented in
the scripting components.
However, encouraging this as 'default' writing is problematic when
ooRex can also implement uno objects ( can it ?).
In pyuno, you can implement uno objects simply by implementing a
python class with the relevant methods and signaling via the
getTypes() call, which interfaces you implement. When local uno code
calls local uno objects, these calls are direct python calls (no uno
runtime inbetween).
So currently, my scripting components workaround will not work with
local objects, because there is nobody, that translate
com_sun_star_foo_XFoo_doSomething() to doSomething() (or the other
way round).
Doesn't Python let you have some catch-all method (a la Smalltalk's
doesNotUnderstand) that could translate a call to
com_sun_star_foo_XFoo_doSomething to a call to just doSomething?
That's *exactly* the mechanism that I am employing for ooRexx (which
draws a lot of its OO-concepts from Smalltalk; in ooRexx it is called
the "UNKNOWN" mechanism which gets triggered, if an object receives a
message it "does not understand", which actually would be used in the
ooRexx runtime error message, if the situation is not handled by the
program).
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
