Geometry Boost List: Re: [geometry] Run-Time specified geometries

Subject: Re: [geometry] Run-Time specified geometries
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2014-05-15 05:32:30

Hi Samuel,

> As discussed with Adam, this needs to be fixed, and the policy needs to
> > be more closely followed. It's not important only for what you're trying
> > to do: the support status is wrong if this rule is broken. This would be
> > the first thing to do.
>
> OK, so we should assume that a dispatching based on not_implemented_tag
> is reliable to implement the runtime layer and/or fix it if necessary.
>

Yep that's a reasonable assumption for now.

> How shall we handle the cases when strategies or sub-algorithms called
> from a main algorithm are more restrictive than the main algorithm ? In
> this case not_implemented_tag should match the intersection of the
> implemented strategies or sub-algorithms...
>

I would need specific examples, and it's possible that the solution will
not be the same for each case. Have you come across many of them? Just
wondering if this should be postponed to a second phase of development, we
will probably see clearer then.

> GIL has a runtime layer on top of the core library. But maybe they don't
> have to manage the extra complexity of algorithms that are not
> implementable for some combination of images (color depth/channel
> order/etc).
>

I don't have an accurate knowledge of GIL but it seems to me that the set
of concepts they work with is way simpler, and indeed they probably have a
much simpler combination of algorithms and data types.

> > Unfortunately I'm busy finishing variants work, only 1 or 2 algos left
> > but I really don't have much spare time for doing any work currently.
>
> I have just send a PR for the distance algorithm. Do you have some tests
> that cover the variant part for other algorithms that I could use as an
> example ?
>

I'll read through that. You can find in the tests for any other algorithms
how I wrote variant tests. I tried to have always more or less the same
approach, when possible. Basically it's pretty simple: when it comes to
calling something like check_geometry(geometry), I also build a one-type
variant with the geometry type under test, initialize it with geometry and
call check_geometry again with that variant. I don't really try to play
with multityped variants as the underlying mechanism is the same and I
really don't see what could break that doesn't break with a mere one-type
variant.

Regards
Bruno