minutes of ESC call ...

[Stephan Bergmann]

On 03/02/2012 11:35 AM, Michael Stahl wrote:
> On 02/03/12 10:32, Michael Meeks wrote:
>> On Fri, 2012-03-02 at 09:29 +0100, Stephan Bergmann wrote:
>>> Micheal, I think I still don't understand what you are up to here.  What
>>> does logging have to do with XUnoTunnel ?
>>
>> 	Correct me if I'm wrong, but as soon as we start doing bridging - which
>> is necessary for logging - then instead of passing C++ object handles
>> around which will dynamic_cast<>  properly, we end up with some bridge
>> object in the middle instead, and all instances of dynamic_cast break -
>> is that right ? :-)

It depends.  If the code that does the dynamic_cast is in the same UNO 
environment as the object being casted, then, thanks to UNO's 
short-circuiting, references to the UNO object are always direct 
pointers to the C++ object inside that environment.

So, looking at the common case where some UNO object C++ implementation 
(a) creates another "child" UNO object C++ implementation via new, (b) 
passes it out, and (c) obtains it back and uses XUnoTunnel or 
dynamic_cast to get at the child's implementation: this should continue 
to work even with the LogBridge.  (Which, in turn, implies that the 
LogBridge does not log intra-environment calls among objects.)

>>>    (And we want as little as possible of the XUnoTunnel hack, anyway,
>>> so no idea what your "dynamic_cast<>  alike" idea is?)
>
> the problem is that sometimes XUnoTunnel is necessary, e.g. you in our
> applications where UNO is not used internally, but has been tacked on as
> wrappers, you cannot implement a method that takes a parameter which is
> from the same application and do anything useful with it without
> XUnoTunnel (or dynamic_cast), because the UNO API (of course) does not
> give access to (necessary) implementation details.

I've never given much thought to dynamic_cast vs. XUnoTunnel (at least I 
don't remember right now I ever did; searching old mail archives would 
probably prove me wrong) -- to me XUnoTunnel was always that rarely 
needed hack where the notational overhead doesn't really hurt.  But 
sure, for the UNO wrappers in the application layers things look 
different.  Anyway, thinking about it now, I see no reason one could not 
use dynamic_cast instead of XUnoTunnel in the scenario outlined above.

>> 	Well - so - my wonder was whether we could create something much
>> lighter, that does XTunnel's job - built into the UNO core code itself,
>> and bypassing such bridges (with some suitable simple, pleasant and
>> readable syntax as dynamic_cast<>).
>
> so you want an uno Reference that points at a (potentially) remote
> object, but still want to get a C++ pointer to that?  i don't believe
> there's a simpler solution than XUnoTunnel for this without giving up
> safety.

So either dynamic_cast works, so you can use it, or it does not work, in 
which case there is apparently no way to (and no sense in) obtaining a 
plain C++ pointer to the object.

>>> Make it into a "random UNO improvements" project?  Hm, not sure.
>>
>> 	;-) well - as you like. IMHO it makes sense writing these things up in
>> some detail for people new to the project.

Makes sense for sure.  Now only need to get that writer's block out of 
the way... ;)

> hehe, to me it looks mmeeks just wants to get you to mentor anything at
> all  ;)

Feels like that.  ;)

Stephan