Re: RFC removing the XPrimitive2D (and related) UNO classes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread 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

_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux