Re: [boost] [geometry] area, length, centroid, behavior

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2009-03-05 18:23:07

Hi Luke,

>> This is something I had thought about. I was wondering if all the
>> library authors could produce a kernel together, and continue to work
>> separately but on this same kernel. And the kernel would be proposed
>> as Boost.Geometry before any other more specific work. But I have to
>> elaborate all this, it's a bit unclear to me for now...
>
> This sounds fine to me.  I have already released my concepts based API to internal users who are very happy with it.  Changes to the names of concepts and mechanisms of generic function overloading would be easy for them to accommodate as long as I can do with an eventual boost geometry concepts type sytem what I can currently do with what I have.  I will be sure to point out which design decisions are important for me to support my exisiting API.

Nice to see you agree with this idea :-) We'll have to identify
exactly what makes our cores diverge and what makes them converge, and
see where we can merge and where we have to make a choice. I remember
that you use SFINAE after having tried tag dispatching, exactly the
inverse of what we did. A good start would be to compare both
approaches. I have to take a closer look at your library to understand
clearly all that.

Anyway, whatever the design we end up with, it will have to ensure
that you can still do what you can do right now, as well as for us.
The contrary would be an obvious proof of failure.

> Funny you should mention CGAL, I have been clarifying the way in which CGAL's type system works to include discussion of it in my paper.  CGAL kernel is not in anyway analogous to our concepts core.  They use the term concept in their documentation, but its definition is different.  It is merely a mechanism for them and their users to easily define new geometry data types that are able to interoperate with their API, not a way to allow data types that don't depend on CGAL header files to interoperate with their API.  That is not possible with CGAL, but I am told they are considering adding it.

Indeed that's really different from what I thought, for me CGAL was
able to handle any foreign data types, exactly like what we do. If
things are that way, then "kernel" doesn't really reflect the nature
of our work indeed.

> We should not use the term kernel.  I would treat it as almost as sacrosanct as a registered trademark and steer clear of comfusing people by avoiding it.  I suggest geometry concepts core.

I had also thought about "core" before so I'm OK with that.

> I am not reluctant to collaborate.  We will have a boost geometry library much sooner by working together than by competing.  It is not really accurate so say both parties, however, because Brandon Kohn, while not as vocal as myself, has proposed a goeometry library at least equal merit.

Yes of course, I was mentioning you because we have communicated much
more with you for now, but if Brandon is also seduced by the approach,
it would be great to see him join us.

Anyway all this sounds really interesting. Don't know yet if it's even
possible, but at least we can give it a try.

Regards
Bruno