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-03 04:50:07

Hi,

Sorry for the late reaction on this. I basically agree with what was
discussed so far, just to specifically answer the original questions:

1. Testing if not_implemented_tag is a base class of the dispatcher is
> not (yet) reliable. For simple algorithms like distance it works but for
> algorithms that depend on others it won't. Concrete example : intersects
> calls extreme_points. extreme_points is not implemented for anything
> else than rings, polygons and boxes. Yet this limitation is not
> "reported" to the intersects dispatcher.
>

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.

> 2. The dispatcher is an implementation detail (not a public interface)
> so should we rely on it ?
>

Same as Adam said, not to be used by external users but definitely
something we can rely on within the library. We have always made sure to
have very consistency interface here, and it was made fully consistent when
support status was implemented.

> 3. The filtering should happend after the variant resolution that means
> rewriting all the variant code in the runtime extension. Unless a hook
> is implemented to augment this code with "runtime filtering".
>

That would be another stage in the multistage dispatching I've put in
place, or maybe directly done within the variant resolution stage.

> 4. Maybe an extension is not a good idea and runtime support should be a
> core functionality of the library. I think so because it seems to
> require an extra requirements : the algorithms must report compile time
> errors in a specified way when invoked with not supported types not just
> rise an MPL assertion.
>

To me it's completely obvious that this cannot be an extension (and
shouldn't, conceptually). It's probably impossible to implement it in a
non-intrusive way. It has to be implemented as a core feature.
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.

Regards
Bruno