Re: [boost] Yet another bignum type

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_integer;
    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.
Regards,
--
Herve Bronnimann