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
Hi,
On Tue, Apr 14, 2020 at 1:38 PM Thorsten Behrens
wrote:
> Noel Grandin wrote:
> > It seems to me that in quite a few places we are using UNO as a
> > means of papering over circular dependencies.
> >
> Would call that papering over - ain't that quite standard-issue
> dependency-inversion?
>
Hi Noel,
Noel Grandin wrote:
> That is kind of my point - here we have gratutious use of UNO, with
> no real means of an extension using it, which is just making it
> harder to optimise an important of our system.
>
The main point I'm disputing is the 'making it harder to
optimise'. From the
Noel Grandin wrote:
> It seems to me that in quite a few places we are using UNO as a
> means of papering over circular dependencies.
>
Would call that papering over - ain't that quite standard-issue
dependency-inversion?
Cheers,
-- Thorsten
signature.asc
Description: PGP signature
On 2020/04/14 12:31 am, Thorsten Behrens wrote:
Don't quite see the logic here - I'd hate to lose API, which in
principle (if something's missing, bug report appreciated) allows
external code to do cool things. The code removal in gerrit IMO is
gratuitous, you could simply overload
On 2020/04/13 9:34 pm, Tomaž Vajngerl wrote:
Yeah, that looks great to me, but I don't like that dynamic / static loading of svgio library (like we already do in
I'm just exposing an already-existing dependency here - currently the dynamic
loading happens inside the UNO layer.
It seems to
Hi Tomaž, hi Noel,
Tomaž Vajngerl wrote:
> On Mon, Apr 13, 2020 at 7:46 PM Noel Grandin wrote:
> > The benefit is that it becomes easier to optimise the copying and moving
> > around of this stuff if it is C++ layers all the way down, with no UNO
> > stuck in the middle of it.
> >
>
Don't quite
Hi Noel,
On Mon, Apr 13, 2020 at 7:46 PM Noel Grandin wrote:
> Hi
>
> I notice when performance tuning that our drawinglayer stuff spends quite
> some time converting back and forth between XPrimitive2D and BasePrimitive
> stuff and copying sequence->vector and vector->sequence.
>
> Now as far
Hi
I notice when performance tuning that our drawinglayer stuff spends quite
some time converting back and forth between XPrimitive2D and BasePrimitive
stuff and copying sequence->vector and vector->sequence.
Now as far as I can see (analysis below), the stuff exposed in our UNO
layer is not
