Hi,

On Mon, Feb 8, 2021 at 6:22 PM Noel Grandin <noelgran...@gmail.com> wrote:

>
> TLDR; I intend to merge the Sdr/Svx objects and their UNO siblings
>
> I was motivated by this by a combination of seeing
> (a)
> https://wiki.documentfoundation.org/Development/Budget2021#UNO_API_at_SdrObjects
> and
> (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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to