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 ? :-) > >> (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. > 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. >> 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. hehe, to me it looks mmeeks just wants to get you to mentor anything at all ;) _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
