|
Boost : |
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2007-10-08 22:49:39
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk