From: Herve Bronnimann (hervebronnimann_at_[hidden])
Date: 2006-11-29 12:25:48
On Wednesday, November 29, 2006, at 07:54AM, "Maarten Kronenburg" <M.Kronenburg_at_[hidden]> wrote:
>> The unsigned integer inherits from the signed one. While this does model
>>arithmetics correctly (a natural number is an integer, after all), it is the
>>unsigned integer that has richer functionality. It's clumsy and not
>>extensible to use inheritance in such a case.
>The normal and the unsigned integer have the same functionality, only the
>implementation is slightly different.
I've heard this often enough since the beginning of this discussion, and imho it's a major source of confusion and problems in the design. Google "Liskov Substitution Principle", "ISA Relationship" or other similar keywords, for more information. The famous example is Shape/Rectangle/Square (read http://www.objectmentor.com/resources/articles/lsp.pdf for a good discussion).
So I have to say this loud and clear: a natural number <NOT> "is a" </NOT> integer. It is not, no more than a modular one is. Try subtracting 1 to 0, and you will not get the same behavior in either three types. This violates the LSP (Liskov Subst. Princ. mentioned above)
However, a const_unsigned_integer "IsA" const_integer, so long as you can't modify the value. Thus if you think of integer as a value semantic type, all is well in your relationships, but the presence of operator--, etc. dictates that unsigned_integer and integer should be unrelated classes. There is a hierarchy, equivalent to the famous example of Shape/Square/Rectangle, where (loosely speaking, and without syntactic rigor):
class const_unsigned_integer : public const_integer; // a natural number is an integer, when talking about value semantics
class integer : public const_integer;
class unsigned_integer : public const_unsigned integer;
But note that the fourth side of the rectangle (unsigned_integer: public integer) is *not* provided.
The same goes even more drastically with modular_integer where some operations (operator<) don't make real sense.
I think this was mentioned back in June, perhaps not in such details, but I remember some people objecting to the inheritance back then. I think you should think about this seriously, Maarten, since imho it's a major flaw in your design, not taking any position on allocators or other issues. I don't have a particular opinion about how to fix the proposal, but I just want this forum to be at least aware of the issues.
-- Herve Bronnimann
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk