Re: ADC Core Data article

FROM : Marcel Weiher
DATE : Thu Apr 07 19:13:16 2005

On 7 Apr 2005, at 16:55, Marco Scheurer wrote:

> [ valueForKey:@"name" vs. name


> And you forgot (or considered it part of 1.):
>
> 5. The compiler is likely to warn you if employee does not respond 
> to name.


Yes, that is part of the larger issue of embedding (mini-)languages 
in other languages:  your original language will typically know 
nothing about your embedded language, and therefore can't even check 
if it is even syntactically OK at the coarsest level.  Same applies 
to SQL-like query languages or XQuery expressions etc.

On the other hand, the expressiveness gained by these mini-languages 
is significant.  So what to do?  I think a promising path is to allow 
the original language to be extended in a controlled fashion.

For example, when something like KVC was needed in ThingLab ( ca. 
1979 )(1), they just extended the Smalltalk system they were using to 
allow path expressions to be used directly in the language.  That's 
one part of the equation.  The other part is reifying the concept of 
reference, so that you have a "reference" object that provides access 
to another object (usually relative to a base object).

For example, MPWFoundation provides a "soft pointer", which is really 
nothing but a reified variable (something very similar was recently 
suggested to 'untangle' object oriented composition).  To stay with 
the example, you might initialize such a soft pointer using a HOM:

    softPointer = [[employee reference] name];

Now you can use this soft-pointer very much like you would have used 
a KVC path, but without having to use an unchecked string, and 
without having to reparse that string every time the reference is 
used.  (Of course, it is also possible to use a string to initialize 
the pointer, but strings dont' become a fundamental means of 
communicating such references).

>

>>> Of course, this is not a sign that either is better -- 
>>> programmers get significant benefits from using C instead of 
>>> assembly, and from using Objective-C instead of C, and from using 
>>> bindings instead of straight method calls.
>>>

>>
>> While I agree that KVC and bindings can provide benefits, I am not 
>> convinced that embedding a string-based mini-language is the best 
>> way to obtain those benefits.  It certainly has significant 
>> drawbacks.
>>

>
> I like bindings. Being able to hookup as easily a control or 
> preference panel, not having to write all these synchronization 
> methods between your model and your view is really neat. And in 
> some case the result is likely to be more optimized than what you 
> would care to do by hand (for instance redrawing a single cell in a 
> table view when one attribute of one object in a collection changes 
> vs using reloadData).


Definitely.  Programming with constraint systems definitely makes a 
lot of things a lot easier, as they take care of a lot of mundane 
data shuffling.  In fact, full-fledged constraint systems do a lot 
more, keeping a whole set of variables/parameters consistent 
according to global equations (keeping stuff in sync is a subset 
where the only operation allowed in constraint equations is equality).

However, I would much prefer a system that would allow me to express 
those constraints *directly*, just like I can now specify message 
sends directly (instead of indirectly, for example by parametrizing 
objc_msgSend() ).  Coming back to ThingLab, it just had a 
"constraints" section:

Part Descriptions

Line: a line

midpoint: a point

Constraints

(line point1 + line point2) /2 = midpoint

midpoint ¬ (line point1 + Line point2) / 2

Line point1 ¬ line point2 + ((midpoint-Line point2)*2)

Line point2 ¬ line point1 + ((midpoint-Line point1)*2)


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. :-)


> But I've never been a fan of KVC per se. In fact I consider using 
> [employee valueForKey:@"name"] in one's code an ugly fault of style.


Yes, I agree.

Marcel


(1)
@article{357147,
  author = {Alan Borning},
  title = {The Programming Language Aspects of ThingLab, a Constraint-
Oriented Simulation Laboratory},
  journal = {ACM Trans. Program. Lang. Syst.},
  volume = ,
  number = ,
  year = ,
  issn = ,
  pages = ,
  doi = {http://doi.acm.org/10.1145/357146.357147},
  publisher = {ACM Press},
  address = {New York, NY, USA},
  }

(2)
@inproceedings{504303,
  author = {Klaus Ostermann and Mira Mezini},
  title = {Object-oriented composition untangled},
  booktitle = {OOPSLA '01: Proceedings of the 16th ACM SIGPLAN 
conference on Object oriented programming, systems, languages, and 
applications},
  year = ,
  isbn = ,
  pages = ,
  location = {Tampa Bay, FL, USA},
  doi = {http://doi.acm.org/10.1145/504282.504303},
  publisher = {ACM Press},
  address = {New York, NY, USA},
  }


--
Marcel Weiher                Metaobject Software Technologies
<email_removed>        www.metaobject.com
Metaprogramming for the Graphic Arts.  HOM, IDEAs, MetaAd etc.
        1d480c25f397c4786386135f8e8938e4