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. Luke