That's even worse. ISA relationships are about *specialization* not generalization. If A is a subclass of B then the set of objects which are A's should be special cases of objects which are B's, and by *dint of those special circumstances* have additional capabilities. To give an example from mathematical theory rather than practical programming: a positive integer is a (ISA) number, but it is a special kind of number that by dint of that specialness has the special capability of it being meaningful to ask about its prime factorization. The practical test is whether under virtually all circumstances you would be comfortable "receiving" a (signed) integer when your spec requests an unsigned_integer. I rather doubt it. It is reasonable, however, to receive an unsigned_integer in place of a signed integer IF unsigned_integer is defined transparently -- e.g., so that negate returns the negative of the number (which would have to be a signed integer if the input were a non-zero unsigned_integer). If you wish to have an unsigned_integer class which is closed for negation and subtraction, then either you should give it no formal relationship to signed integer or have them both inherit from an abstract class, call it abstract_integer, whose interface would probably turn out very similar to that of unsigned_integer. Although the spec may be identical the meaning is different. While neither would have negate, or negate would be speced to perhaps throw an exception, an abstract_integer might be negative but an unsigned_integer never would. Topher At 04:03 PM 6/1/2006, you wrote:
Topher Cooper wrote:
<>
The problem seems to me to be the idea that it inherits from integer -- an almost classic example of misuse of inheritance. Pardon me if I lost the thread somewhere but that seems to be what is being proposed.
As others have said, inheritance should represent ISA both in interface and conceptually. If unsigned_integer followed this relationship than there would be no argument here -- the negative of an unsigned_integer would be clearly and unambiguously defined -- it just wouldn't happen to be an unsigned_integer. But that seems to eliminate the point of having a separate unsigned_integer type. Inheriting unsigned_integer from integer means that I can never be sure that negating an integer (which might actually be an unsigned_integer) is a reasonable thing to do. VERY BAD DESIGN.
Seems to me that, if the author is really set on using inheritance here, integer should inherit from unsigned_integer, since integer can do everything that an unsigned can do, but not vice-versa. Integer extends unsigned with the ability to represent negative values and the result of subtraction.
- Marsh
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost