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

Martin,
   Yes, I agree with what you are saying.  In the current description of 
applyConstraints, we try to avoid the overconstrained issue by testing 
on the  new constraints on a copy of the object with all constraints 
removed.  (We can't remove the constraints from the real object until we 
know that the new ones can be satisfied.)

- Jim
On 2/7/2014 1:20 PM, Martin Thomson wrote:
> 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.

-- 
Jim Barnett
Genesys

Received on Friday, 7 February 2014 18:24:31 UTC