Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-05 05:40:00

Salut Vicente, :)

> From: vicente.botet

> There is a thing that i don't like in the design, the fact 
> that you can change the constraint at runtime.

If you use a constraint that works statically then there is no way to change it.
It is bound to the constrained type.

> I would prefer 
> to have two separated hierarchies, one for constrained values 
> that preserv its constraints, error handling, ... staticaly, 
> and one for those tyhe constraint can be changed at runtime.

I wouldn't prefer to have two separate hierarchies with almost identical
functionality and differing only in details.

> I expect that the preserving constrained values be 
> implemented in a more space and time efficient way. 

Did you find any problems with suboptimal work of the current implementation for
the static cases?

> For the constrained values that can change its constraint at 
> runtime I see two cases, the constraint is attached to the 
> instance, which is your case, or it attached to a type. 
> 
> mutating_type :== by_instance | by_type
> 
> When attached to a type, the type needs to maintain the set 
> of instances. Instead of changing the type a split operation 
> can be provided  resulting in a transfer of the instances 
> satisfying the new constraint to the new type. Of course this 
> meens more space and time consumming, but ...

There was a similar idea on the users list and I'm still not convinced this
leads to something good.
If you request to change the constraint of a whole type and some instances don't
obey your request, then what is the point in doing this?

Best regards,
Robert