Issue 66635 - Core reflection should allow browsing Type s
Summary: Core reflection should allow browsing Type s
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: OOo 2.0.3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-06-22 13:31 UTC by ramon_garcia
Modified: 2013-02-07 21:52 UTC (History)
2 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description ramon_garcia 2006-06-22 13:31:52 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.
Comment 1 kay.ramme 2006-08-11 13:43:54 UTC
Sorry for the delay. I am going to take a look at this in about two weeks ...
Comment 2 kay.ramme 2006-09-28 09:53:52 UTC
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).


Comment 3 kay.ramme 2006-09-28 10:00:25 UTC
We may than add this to the Uno todos list. See

Comment 4 kay.ramme 2006-11-09 09:26:01 UTC
Going to close this ...
Comment 5 ramon_garcia 2006-11-09 16:05:30 UTC
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.
Comment 6 Stephan Bergmann 2006-11-10 09:01:17 UTC
Generally, I think 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 further with methods for
which there are already obvious and unproblematic workarounds.
Comment 7 ramon_garcia 2006-11-10 19:09:44 UTC
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.
Comment 8 Stephan Bergmann 2006-11-13 12:26:45 UTC

- "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.
Comment 9 ramon_garcia 2006-11-13 14:19:36 UTC
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.