Re: [boost] [GTL] - geometric template library - determininginterest

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-10-09 03:48:12

Simonson, Lucanus J wrote:
> Joel wrote:
>> Ok, another example to clarify my point. Say I have a legacy type
>> for a point defined like this:
>>      typedef int64 point; // where the high 32 bits is x and low, the
> y
>> Now how do I inherit from that?
>> All I am saying is that there is a better, more generic way.
> 
> In this, as in anything, there is a tradeoff.  In designing the design
> pattern I made a lot of tradeoffs with the aim, always, of maximizing
> user productivity and ease of integration of the library while not
> sacrificing performance or portability.  Inheritance limits what
> qualifies as a valid data type for a geometry object that is compatible
> with the design pattern and excludes basic types and
> pointers/references.  If there were a real need to include such it might
> argue in favor of composition as an alternative but I don't see how it
> argues against both inheritance and composition.  The truth is I could
> use either or mix and match the two as needed and the API and usage
> would be identical from the user's point of view.  I would probably have
> to use composition if I wanted to apply the design pattern to something
> simple like the coordinate data type, or an iterator, though I don't se
> why I would want to do such a thing.
> 
> You are saying there is a better, more generic way, but you aren't
> explaining why it is better, or how the ability to generalize basic
> types and pointers makes it a good tradeoff to apply it instead.
> Explain to me how you think I could accomplish the same things with less
> code, less error prone, clearer and easier to understand.  I really do
> want to improve the library.  If you have an improvement to offer, it
> isn't even enough that I take your word for it, I have to be able to
> explain why it is an improvement to my users and convince them of it.  I
> tried to explain that non-member, non-friend functions were supposed to
> be the way to go with the first revision of the library, and they
> overruled me.  In the end I agreed with them that having objects that
> fully encapsulate the behavior of geometry types is nicer and worth some
> effort, maybe even make a tradeoff or two to get it.

Hmmm, you guys are the ones proposing GTL to boost, right? Shouldn't
you be the ones convincing Boosters why your approach is better
(if you think it is)? I've enumerated a couple of flaws with it
as a general concept modeling scheme and mentioned a couple of
existing libraries (including STL) that use different schemes.
There are at least 2 main flaws with it as a general modeling scheme:

1) It is not generic enough. It relies on inheritance, a very tight
    coupling mechanism, and not all c++ objects can be inherited
    from. It cannot even model STL's iterator concepts (e.g. pointers).
    You say that you can use composition instead. Sure! But that too
    has its flaws. It will require that the object is at least copy
    constructible and/or assignable. Some objects are inherently
    or even explicitly not.

2) It is unnecessarily verbose. Consider the fusion examples I presented:

     std::pair<int, short> p(1, 2);
     fusion::for_each(p, cout << _1);

     boost::tuple<int, short> t(1, 2);
     fusion::for_each(t, cout << _1);

     boost::array<int, 2> a(1, 2);
     fusion::for_each(a, cout << _1);

Now, if I were to use your modeling scheme, that would end up
looking like:

     std::pair<int, short> p(1, 2);
     fusion::for_each(
         ForwardSequenceConcept<std::pair<int, short> >::mimic(p), cout << _1);

     boost::tuple<int, short> t(1, 2);
     fusion::for_each(
         ForwardSequenceConcept<boost::tuple<int, short> >::mimic(t)
       , cout << _1);

     boost::array<int, 2> a(1, 2);
     fusion::for_each(
         ForwardSequenceConcept<boost::array<int, 2> >::mimic(a)
       , cout << _1);

Sorry, no thanks. To me, it's quite clear which one is better.

Don't get me wrong, I am not in any way attempting to convince you to
change your library. I'm quite sure that you have a well tested,
seasoned, industrial strength library. I wouldn't even get in the
way when it eventually gets into boost for review, regardless of this
/unique/ modeling scheme. As you say, there are alternate ways to
do what you want in C++. Fine! It's ok. What I am airing is my
concern that this concept modeling scheme won't hold in the more
general case, like say, in the related thread discussing about
a Boost Point type. That's where my objection lies. There are better
concept modeling schemes that do not exhibit the flaws I mentioned.
And the good thing is that these "better" schemes can encompass your
scheme, so, no problem.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net