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