Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Philippe Mougin <email@hidden>
- Date: Tue, 4 Jan 2005 02:48:28 +0100
Izidor Jerebic wrote:
> 3. Procedural thinking - objects as structs
> This is the major one, and the most problematic. Cocoa
> Bindings' mental model is of objects as passive lumps
> of data.
Izidor, you've hit the nail on the head. Cocoa Bindings are not object
oriented.
It doesn't come from Bindings themselves but instead from Key-Value
Coding. Actually, everything that is based on KVC (more and more things
are) become largely de-objectified. This is not surprising, since KVC
introduces a non-object-oriented programming model. In this model,
instead of sending messages to objects, we associate values with keys.
Of course, since Cocoa was originally heavily object oriented,
technically we still use objects when using KVC. This is why we still
see objects, object controllers, method invocations everywhere.
However, conceptually, we don't use them as objects, but as
dictionaries, or, as you put it, mere structs, with the nuance that, by
implementing accessors, we can still execute custom code when a field
of the struct is read or written. A bitter consolation if, like Alan
kay, you think that "objects should be presented as site of higher
level behaviors" and that "[with objects] you can now replace bindings
and assignment with goals" (cf. "The early history of Smalltalk", Allan
Kay, Apple Computer).
Most of what makes the power and appeal of object-oriented programming
is missing from the KVC programming model. However, KVC has its own
virtues, its own power and appeal, along with its own limitations.
Apple has chosen to use a non-OO programming model to offer various
very powerful services like Bindings, and Core Data (supposing its
design is in line with EOF). I believe (without certitude, but from a
good experience in the field) that the problems solved by KVC, and the
services built on it, could have been solved on top of a more
object-oriented model than KVC. And I also think that doing so would
have shielded us from this kind of insane complexity we sometimes
encounter in Bindings. Beside, doing so would also have permitted to
use the object support we have natively in Objective-C. On the
contrary, KVC is not directly supported at the language level, and we
have to use it at the framework level (e.g. specifying keys in
NSStrings etc.), which is much more brittle. However, if you look
closely at the problems in question (i.e. the problems solved by KVC
and the upper layers), you see that solving them using an OO model
would not have been that easy (to say the least) and might have
required to extend a little bit Objective-C, which has limitations
coming from the fact that it is a compiled language instead of an
interpreted one. BTW, this limitation is "solved" in KVC by introducing
a little interpreted layer, with its own language (i.e. the language
you use when describing keys and keypaths, with array expressions and
co.)
With KVC, Apple made a pragmatic choice driven by its own technical
evaluation and its experience, heavily influenced by the EOF/WebObjects
team. And now they are going forward full speed with it and doing cool
things (I mean, its not because a technical approach is not
object-oriented that you can't do great things with it). Nevertheless,
it is somewhat ironical to see that they have succeeded at imposing a
non-object-oriented programming model on top of an object-oriented
language, and right in the middle of one of the historically mythical
object-oriented framework.
Many parts of Cocoa are still very object-oriented and will forever be,
but it is clear that with more and more things using KVC as the
fundamental paradigm, Cocoa is, in a sense, in the process of becoming
less object-oriented. Personally, I'm not a fan of this trend, since I
like object-oriented programming more than KVC-oriented programming
(and I think the former has a more promising future in computer science
that the later). I'm glad that I love some other trends in Cocoa, like
the fact it is becoming more and more powerful, with new functional
areas covered with each release...
Best,
Philippe Mougin
http://www.fscript.org
_______________________________________________
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