Boost logo

Boost :

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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at