Re: ADC Core Data article

FROM : Marcel Weiher
DATE : Thu Apr 07 21:03:10 2005

On 7 Apr 2005, at 18:55, Scott Stevenson wrote:

>
> On Apr 7, 2005, at 10:13 AM, Marcel Weiher wrote:
>
>

>> The system would now make sure that these constraints always 
>> held:  if you changed the end-points, the midpoint would be 
>> recalculated, if you changed the mid-point, the end-point(s) would 
>> be adjusted.  Objects with these constraints could be composed, 
>> so multiple constraints (in a hierarchy) were considered to arrive 
>> at the final values.  The application to keeping UI synchronized 
>> with model objects is hopefully obvious. :-)
>>

>
> I think you could make the case that Cocoa Bindings and EOF do the 
> same thing, conceptually.


Precisely.  Well, sort of...

> Or have I missed your point?


...the point is that Cocoa bindings (and the respective parts of EOF) 
represent a 'sort-of-kind-of' and quite limited constraint 
satisfaction system (as far as I can tell!), except that it doesn't 
actually come out and say that that's what it is.  It also doesn't 
provide us with any linguistic means of *directly* specifying 
constraints, instead exposing us to the mechanics of how one would 
interact with a possible *implementation* of such a system.

Interacting with something without the right theoretical framework 
(at a minimum: terminology), is quite cumbersome.

> In Panther terms:
> +setKeys:triggerChangeNotificationsForDependentKey:
>


QED.  :-)  While that method (and the mechanism it represents) 
provides me with some of the mechanics I can use to maintain 
constraints, it doesn't allow me to simply *state* the constraint.

Why can't I write something like the following:

constraint:
    employee.name = myTextField.stringValue;

This now makes sure that these two values are kept in sync.  And if I 
add another constraint:

constraint:
    employee.name = myTextField.stringValue;
    employee = tableView.currentRow.dataObject;

the system will make sure that all of these are kept in sync.  (These 
are only simple equality constraints).

Constraints can also be dynamic, to implement dragging, you say that 
an object's coordinates must be the same as the mouse-coordinates 
while the mouse-button is pressed etc.

Constraint satisfaction is not exactly something brand new, in fact 
the beginnings date back to Sutherland in the late 60ies and ThingLab 
was 1979.  A lot of strides have been made since then, both in 
extending the applications and the constraint solver technology to 
support them.  (Incidentally, spreadsheets are simply constraint 
engines as well...)  Virtually all constraint solvers allow multiple 
simultaneous constraints (with varying strengths) to be set, with the 
solver taking care of finding a solution that will satisfy all 
constraints (or moaning when that isn't possible).


Cheers,

Marcel