Apache OpenOffice (AOO) Bugzilla – Issue 66635
Core reflection should allow browsing Type s
Last modified: 2013-02-07 21:52:35 UTC
The XIdlReflection allows one to browse a type by giving an Any containing it, by giving the name of the type, but, surprisingly, not by giving the type itself. The implementation of the Core Reflection service (stoc/stoc/source/corereflection/crefl.cxx) does internally support building a type browser XIdlClass from a type (methods forType). Why not exporting this functionality? This is needed in several places, such as the basic interpreter, and the introspection service. What that code is doing currently is using access to an interface by name, using the forName() method. This is likely to be inefficient, since it involves looking up a string in a dictionary.
Sorry for the delay. I am going to take a look at this in about two weeks ...
Hi, would you mind discussing this at dev@udk mailing list? May be with concrete pointers to the locations where it could be used (I assume the code would become somewhat simpler). Kay
We may than add this to the Uno todos list. See http://wiki.services.openoffice.org/wiki/Uno/Todo
Going to close this ...
Sorry for not answering. I am rather busy with my daily job. The background for this suggestion came after doing a Summer of Code grant. I needed to browse a Type, but I did not have any straightforward method for converting it to a XIdlClass. Note that if one wants to browse a live object, one first querys the object XTypeProvider method and thus obtains a Type. Thus the need for this functionality should be clear now: to browse a live object. It is also pretty straightforward to implement. I am sorry if the need for this functionality was not clear before.
Generally, I think com.sun.star.reflection is already in a rather messy state. The XIdlClass and XTypeDescription concepts present similar information in two independent ways. Ideally, this would have been combined. @ramon_garcia: From what you write I understand that XIdlReflection.forName is a workaround for the functionality you miss (mapping from UNO TYPE to XIdlClass), but you fear that the workaround has negative performance implications. Did you measure that or is it just a gut feeling? I would not want to complicate the messy com.sun.star.reflection further with methods for which there are already obvious and unproblematic workarounds.
The issue is not so much performance as compatibility. One can learn what Types an object is providing through the XTypeProvider interface. An alternative interface to XTypeProvider would require to change all object implementations. With regard to general ways of improving reflection. My personal view is that objects should not implement XTypeProvider nor anything like that. This requires too much per-object work, and thus taking more memory and programming work. Objects should have minimal per-object information. For instance, an object could have a method getSerivceGUID that returns an identifier for a service; and the method implementation should be provided by the UNO framework. On the top of this functionality everything else could be implemented, by browsing the description of a service in a type library.
@ramon_garcia: - "The issue is not so much performance as compatibility." Sorry, I do not understand this. Why would something different than XTypeProvider be necessary? - "My personal view is that objects should not implement XTypeProvider nor anything like that." Ideally, functionality like XTypeProvider should be part of each UNO language binding, instead of the UNO API (however, UNO language bindings are already supporting the existing functionality well, e.g., cppuhelper's C++ implementation helpers provide the necessary stuff). "an object could have a method getSerivceGUID that returns an identifier for a service" There is a fundamental mismatch between UNO objects and UNO services---a UNO object can implement more than one service, or none at all.
Sorry, sb, I had not understand you before. The issue with the current method of obtaining a XIdlClass from a Type is that it is unnecessarily complex. It is against common sense that one should obtain the name of a type, and then obtain a XIdlClass from it. It makes the developer spend time looking for a different way, since one thinks "it is not likely that this is the intended way". The complexity added is minimal. The method implementation is a one-line. The real issue is not so much performance as it is cleanness, maintainability and simplicity. If one reads code Reference<XIdlClass> t_refl = core_reflection->forType(t); then the code expresses perfectly the intention of the developer. From the performance point of view, the current method goes from a type to a name, and then CoreReflection::forName() goes from the name to recover the original type. Although It is not necessary to make a benchmark to know that it cannot be optimal, the added implementation complexity is more important than speed.