Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Brent Gulanowski <email@hidden>
- Date: Thu, 6 Jan 2005 13:35:56 -0500
On Tue, 4 Jan 2005 02:48:28 +0100, Philippe Mougin <email@hidden> wrote:
> 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.
Terribly sorry for coming in so late. If I repeat anything, again I
apologize, but the rest of this thread is way too long to read for my
simple replay.
I know what you're getting at, Philippe (or believe I do), but I'm
sure you know that that KVC using the standard Objective-C messaging
model as much as anything.
What KVC takes advantage of, and KVO as well, is additional runtime
support which seems to step outside of the usual encapsulation bounds.
(Of course, those who dislike it can certainly defeat it by
deliberately breaking KVC compliance, but that would be paranoid.) But
I say, "seems to" because the knowledge is there -- every interface
file publicly displays the names of the class's attributes. And of
course KVC honours accessors when they exist.
Thus, use of KVC mechanisms still involve nothing but messages, as
Charlton suggests, from the point of view of client objects. While
very simplistic in their contents ("May I have the value for
such-and-such attribute"; "Please change such-and-such attribute to
this value"), this does not change their nature. The methods are
defined in NSObject, as are many other key runtime-leveraging methods.
>From the point of view of vendor objects, KVC depends on a feature of
the runtime, which is NSObject's //ability to be aware of its own
attributes//, an ability which is inherited by subclasses which
conform to KVC requirements. Understandably, runtime features are seen
as magic, because they are not accessible to you without mucking about
with the laws of physics, so to speak.
KVO also depends on a runtime feature, which is the somewhat imperfect
//isa swizzling//. I don't fully understand it yet, and it really
deserves a complete documentation treatment. It's imperfect, as it has
some odd side effects (notably changed -description behaviour), but
Apple is aware of this. It's been discussed before.
To best understand bindings underlying ennabling technologies, you
will have to have good understanding of the Apple Objective-C runtime.
If the documentation is lacking, that will have to be addressed by
Apple Tech Pubs ASAP.
The business of calling bindings non-OOP is a red herring. Vast
quantities of data which are relevant to users are simply not
behaviour-oriented. You don't need to teach tabular data how to dance.
It's fine just sitting there, waiting to be read or written. The most
you would want to ask of it is to protect itself from inappropriate
values, to which bindings is completely sensitive.
Bindings, glue code savings aside, do one excellent thing: they
provide a standard method for performing a very common task in many
programs: that of tying the interface, where user's input and read
data, to the model, where the program stores that data, either
persistently or temporarily between serializations. They address the
difference between stored and displayed formats with value
transformers (which are far more powerful that people often realize),
and they can save a lot of annoying mucking about with
NSNotifications.
I will agree that, while still acknowledging the hard work that has
gone into Interface Builder, the practical work of setting, reviewing,
and debugging bindings needs more work. It would be very helpful to
see, at a glance, the bindings tree, especially when you have a
misspelled or incorrectly bound object. Having to click on all the
controllers to see their bindings list and then monkey around with
them trying to work out which widget is hooked up wrong is tedious.
But then, most software is full of dependency and other implicit tree
relationships, and in general, there is an acute shortage of tools to
visualize them well. It's a great opportunity. It doesn't have to be
Apple who seizes on it.
Now I've gone and written yet another ponderously long e-mail. Sorry about that!
--
Brent Gulanowski
http://www.boredastronaut.com
_______________________________________________
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