Hi Stephan,
> Those services *are* instantiated at the global service manager. It is
> only that they are not typically instantiated with a statically known
> name (where xyz.create is superior to smgr.createInstance("xyz")), but
> rather with a computed one (where xyz.create would be of no use, at
> least in your typical UNO language binding). Again, take a look at the
> UriReferenceFactory example.
Ah, I didn't understand that you were aiming at the URI scheme parsers,
not their factory. Got it now, thanks :)
> The simple UNOIDL syntax "service Service: Interface;" does cause
> default constructors to be generated. Do you know any cases where
> inadvertently the special-case syntax "service Service: Interface {};"
> was used instead? Maybe we can still fix those.
No, I don't know them. I just tried to construct a pretty round-about
argument that a) people seem to know constructors too little b) if they
knew, they would use new-style services more often (as this noticably
decreases overhead when constructing such services) c) such subtle
differences might repel people from using them.
Anyway, not really a big deal, as said, just slightly unexpected.
> The idea was to move service instantiation into the language bindings
> (so, e.g., in C++ a class implementing a service would probably have C++
> class constructors matching the UNO service constructors, or static
> factory methods, etc.).
That's something I didn't dare to suggest :).
Moving the ctor handling to the factories, instead of the current
"always default-construct and then late-initialize" would be even
better. For instance, implementations can get rid of all their "not
initialized" handling, in case somebody creates them bypassing the
explicit ctors, and does *not* subsequently initialize them.
> The current XImplementation stuff is seen as a
> gross hack to implement service constructors (at least by me).
+1
> Unfortunately, this somehow keeps slipping on the urgent todo list...
Sad enough. Whenever I implement constructors, I find it pretty ugly to
do all this manual initialization coding.
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
