Stephan Bergmann wrote:
Bernd Eilers wrote:
Hi there!
[...snip...]
What does the UNO team think is this idea feasible, do you like it?
Not really. There is a mismatch between UNO and Java (e.g., in the one
direction, many Java types have no correspondence in UNO, and in the
other direction, UNO types ANY and com.sun.star.uno.XInterface both map
to java.lang.Object).
Well we could just document which types do have a correspondence in UNO
and which just can not be used. With WebServices in JAX-WS it is quite
similar you just can´t use any java feature in your Implementation class
eg. you can´t overload methods, that´s just something you need to know.
And for the ANY and XInterface both mapping to java.lang.Object problem
we could use guess what "an Annotation" to declared which UNO type the
java.lang.Object is.
And my personal opinion is that (language
neutral) interface design work is quite different from implementation
work, and thus one benefits from clear separation.
That´s understood and a well known and accepted development model of
course. What I am talking about is alternatives that might in some cases
be easier to use. For extension developers it might be a little bit of a
hurdle to need to learn a new component model and to need to specify
their interface design in UNO IDL, they might have their interface
design in the head or somewhere scratched down on paper not using any
formal language at all to describe it. Those could benefit from being
given a method to be able to start their implementation without having
to learn too much new things. Specifying something in UNO IDL is IMHO
not really language neutral it´s just annother language one has to learn
the language neutral thing is the idea one has in his/her head about the
design.
Where Java annotations might be useful is for registering
Java-implemented UNO services and singletons. There is a low prio task
to redesign registration sometime in the future (using a passive
approach rather than the current active one where code from the
component is executed during component registration).
Well OK, something to start with could be just an annotation
@UNOServices or similar taking the names of the services a class
implementes as arguments and use that for service registration purposes.
But why stop at using it for registration purposes when it would also be
easy to create the implementation of the XServiceInfo interface the
class must provide automatically from such annotation, provided that the
new registration mechanism does not eliminate the need to implement
XServiceInfo of course. This would be the most basic feature I was
thinking about, generating IDL etc. by using annotations would be more
advanced features, that may or may not be considered useful.
-Stephan
-Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
