Hello,

some comments inline:

> -1- CoreReflection: Gives access to the methods etc. of the passed type 
> name, respectively methods etc. of the exact type of the passed object. 
> Methods, attributes etc. can be "called" directly. The CoreReflection is 
> only available for Binary UNO, e.g. there is no such service for pure 
> Java-UNO.
> 
> -2- Introspection: Gives access to all methods and interfaces of the 
> passed object as an integrated entity. The Introspection relies on the 
> CoreReflection and on the object to implement the XTypeProvider interface.

E.g. in contrast to the CoreReflection, Introspection unifies property
and attribute information.

> -3- Invocation: A service for dynamically invoking a method of a 
> particular object. This service was designed for scripting languages 
> connection to UNO. It also takes care of needed type conversions etc. 
> The Invocation relies on the Introspection.

No, the invocation code uses the CoreReflection.
Concerning type conversion:
 - CoreReflction only supports simple widening conversion
 - Invocation uses script.Converter service to coerce types

> -4- TypeDescriptionProvider / TypeDescriptionManager: Services providing 
>   access to type descriptions. The TypeDescriptionManager just delegates 
> requests to the registered providers. The returned type descriptions are 
> different of what the CoreReflection provides and are for informational 
> purposes only. E.g. the remote bridges use these type descriptions.

+ the TypeDescriptionManager caches typedescription objects.
+ the TypeDescriptionManager is the only source that reflects all
information of IDL (except for documentation)

> -5- XTypeProvider: An to be implemented interface providing all 
> interfaces of an object, the Introspection and OOo BASIC rely on objects 
> to implement this interface.
> 
> -6- XServiceInfo: An interface providing the implementation name and the 
> supported services of an object. This was/is needed for objects not 
> implemented using the new multiple inheritance stuff.
> 
> If you only need the descriptions, -4- is probably the easiest way. If 
> you dynamically want to invoke methods etc., then -3- makes sense.
> 

> Singletons, as the TypeDescriptionManager, can either be retrieved via 
> the "createInstance" method of the ServiceManager (which returns the 
> same object all the same, in case it is a singleton), or via the 

No, this is wrong. The service manager's createInstance...() methods
semantically always create new objects. If objects are implemented
stateless, you may get the very same instance again, because the
implementor decided to safely do so. IMO Kay thinks of old
"OneInstanceFactory" implementations, which are not stateless. Due to
this mix-up, that concept is considered to be deprecated. The
distinction between singletons and multi-instance is clear:
- a singleton instance is accessed via component context
- a service instance is created via service manager
Singletons, as "/singletons/...theTypeDescriptionManager" can only be
retrieved via the component context, a createInstance call at the
service manager will return a new (uninitialized) one.

> ComponentContext and the "getValueByName" method. The name of the 
> TypeDescriptionManager is
> 
> "/singletons/com.sun.star.reflection.theTypeDescriptionManager"
> 
> If you stumbling over problems when accessing the particular types via 
> one of the above services / interfaces, I suggest to try out what you 
> want to achieve first in OOo BASIC, and to switch later to COM. Only to 
> ensure that there is no bug / incompatibility in the OLE bridge.
> 

-Daniel

PS: good for wiki?

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to