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