Re: [boost] Yet another bignum type

From: simon.sebright_at_[hidden]
Date: 2006-12-01 10:51:06

> [mailto:boost-bounces_at_[hidden]] On Behalf Of Tobias Schwinger
> 
> simon.sebright_at_[hidden] wrote:
> > Tobias wrote: 
> > 
> > 
> >>Maarten Kronenburg wrote:
> >>
> >>>The class represents the set, and an object of that class 
> represents 
> >>>an element from that set,
> >>
> >>Agreed, so far.
> >>
> >>>whether the set is employees and secretaries, or integers and 
> >>>unsigned integers.
> >>
> >>The operations on secretaries are usually a superset of the 
> operations 
> >>on employees, while the operations on unsigned integers are 
> a subset 
> >>of the operations on signed integers.
> >>
> >>Inheritance is only applicable in the former case. The flaw in the 
> >>latter scenario is similar to adding operations specific to 
> >>secretaries, trainees or managers to the interface of 'employee'.
> > 
> > Things like secretary, manager, etc. might better be considered as 
> > roles, an employee might have > 1 role.
> > 
> 
> Sure, if that's what you are trying to model. 
> But what does that have to do with this discussion?

I seem to have joined the thread in the middle, sorry if I am repeating
something already said...

I guess I am reinforcing what I have been picking up on this thread.
I.e. that behaviour of something can be disconnected from what it is (a
square is a rectangle in geometry, but the behaviour of a square object
does not meet the contract of a rectangle object).  In the computer
world, inheritance is a very strong relationship, and needs to be
considered carefully, taking into account the dynamic nature of the
instances.

The above separation of employee/role is a bit of a strategy pattern, I
think.  Maybe it could help the integer issue, such that the various
required integer classes could hook up to sets of behaviour, some in
common, some not.  Traits might be able to contribute too.

Anyway, what about the fact that it is not a good idea to have multiple
concrete classes in a hierarchy?  That would debunk one int class
deriving from another.

Simon