Hi,
On Mon, Feb 8, 2021 at 6:22 PM Noel Grandin <noelgrandin@xxxxxxxxx> wrote:
TLDR; I intend to merge the Sdr/Svx objects and their UNO siblingsI was motivated by this by a combination of seeingand(b) trying to optimise a chart issue where I realised I would need some way to tunnel through the UNO objects to get to the underlying Sdr objects, which are quite capable of performing the required operation efficiently....
Anyway, just checking that no-one has fundamental objects to this idea.
Well, to me it doesn't seem to be a good idea to merge UNO with document model objects. UNO to me has always been a separate thing - a separate, "nicer" view of the document model that is mostly intended for external use (Macros, Extensions) and thus has strong API guarantees. This is the main reason why I think the UNO API should be implemented separately - something that wraps an internal model and it presents it with a nicer and cleaner API, where the API provided should be something that is actually needed for Macro, Extension development and not because it is needed somewhere internally.
Most of the API is implemented like that, but the places that don't have proved itself to just be a PITA to deal with - like chart2, framework, slideshow.
With this merging I think we are just going in that direction again - instead of separating and providing a sane UNO API and a separate internal object model that can be refactored and freely changed, the main driver for the new API will be out of implementation necessity (not what is actually needed by external users) and the internal object model will inherit the stronger API guarantees making changes harder.
So as of (a) - if there is a life cycle problem in the Sdr objects, then we need to solve that, where merging the internal with UNO objects is just one of the possible solutions.
And (b) -- if you need to access the internal Sdr object then you can make the UNO implementation object public, cast to it and get the SdrObject from that. You should be able to do that if the module depends on svx, which I don't see why it should not.
Anyway, just my 2 cents...
Regards, Noel.
Tomaž
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
