Re: ADC Core Data article
Re: ADC Core Data article
- Subject: Re: ADC Core Data article
- From: Marcel Weiher <email@hidden>
- Date: Thu, 7 Apr 2005 20:03:10 +0100
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden