Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index


Hi Tomaž,

Tomaž Vajngerl wrote:
I'd call it a flaw in the dependency hierarchy, which means something is
located at a wrong place.

Not necessarily. Sometimes it's the lesser evil (and there's always
other design constraints). Not saying this is the case here (haven't
looked in any detail if/how this can be disentangled).

I know that this can be a "standard-issue" but mostly because a lot
of times fixing the hierarchy is a lot of work and moving things
around, but this doesn't mean breaking a circular dependency in such
a way should be taken lightly or is a good thing.

Yep.

As for UNO - to me UNO API is for making the functionality available
to extensions, macros, tests. If we use UNO just to circumvent a
circular dependency, how is that anything but a misuse of UNO API?

It's the standard component model for LibreOffice, for better or for
worse. And it's fairly complete with stuff like factories, and more
subtle things like thread apartements.

So using UNO for a bit of fairly self-contained code, that can
usefully be employed by extensions (this "it is not perfect yet, you
cannot use it as-is" is a red herring really), and gives you a factory
that breaks the dependency chain is IMO not a bad thing. Hand-rolling
DLL loading to work around it would be.

If we extend the UNO API from the point were it is not required for
extension development, it is prone to be used for things that were
never meant to be used externally and also YAGNI.

There's some truth to that. But it's very hard to draw lines in the
sand here; there's historically been extensions trying to integrate
_very_ intricately even with document views.

The discussion at hand is a different one though: should we
deliberately _remove_ UNO API, despite there being no technical need,
because we _think_ extension authors wouldn't/shouldn't use it?

(the icing of the cake is of course doing that, and then noticing now
you need to code something like the component factory yourself to get
dependency inversion working)

Cheers,

-- Thorsten

Attachment: signature.asc
Description: PGP signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.