Re: Defining ConstraintSet and the constrainable algorithm in terms of it

On 7 February 2014 09:57, Jim Barnett <1jhbarnett@gmail.com> wrote:
> Not quite.  The problem is that a constraint may have the side effect of
> constraining a property other than the one it explicitly mentions.
> aspectRatio is one example, but a more common one may be ones due to
> resource limitations.  On a certain machine it may be impossible to have
> both foo and bar set to 'high', while on another, less resource constrained
> one, it may be fine.  I think we need a concept like "effective Capability",
> which is the range that the machine is actually able to support, given the
> circumstances and the other constraints that are in effect.  The setting has
> to be in the intersection of the effective Capability and the range
> specified by the constraint.

Let me try to be clearer because I think that what I tried to say was
pretty much what you are saying.

Firstly, I think that capabilities are just "natural" constraints.
That is to say that these are constraints imposed by physics, by
reality.  My camera is constrained to be no more than 720p because
that's just how many pixels it has.  The fact that someone else is
using all the CPU is somewhat more elastic (we could ask them to scale
back), but I don't see any need to consider this class of restriction
any differently.

If you want to model this out, you could have browser preferences
modeled as optional "natural" constraints, but I think that most of
the discussion here relates to the mandatory aspects.

For any constrainable thing, there are multiple sources of
constraints.  When a new constraint is added, it must fit within the
intersection of all the existing mandatory constraints.  The "first"
set of constraints is the natural constraints, but then each new
source adds extra.

The point I was trying to make (poorly) was that when you change
constraints on one constraint source, you first have to remove the old
constraints that that source applied.  Otherwise you end up
overconstrained more often than necessary.

Received on Friday, 7 February 2014 18:21:20 UTC