Re: The magic of Key Value Coding and Key Value Observing
Re: The magic of Key Value Coding and Key Value Observing
- Subject: Re: The magic of Key Value Coding and Key Value Observing
- From: Marcel Weiher <email@hidden>
- Date: Thu, 30 Aug 2007 23:26:00 -0700
On Aug 30, 2007, at 9:29 PM, Erik Buck wrote:
I just can't articulate why I am
uncomfortable with KVC and KVO when I am comfortable
with connections in IB.
Maybe Alan can help?
From "The Early History of Smalltalk", by Alan Kay:
"Object-oriented" Style
This is probably a good place to comment on the difference between
what we thought of as OOP-style and the superficial encapsulation
called "abstact data types" that was just starting to be investigated
in academic circles. Our early "LISP-pair" definition is an example of
an abstract data type because it preserves the "field access" and
"field rebinding" that is the hallmark of a data structure.
Considerable work in the 60s was concerned with generalizing such
strcutures [DSP *]. The "official" computer science world started to
regard Simula as a possible vehicle for defining abstract data types
(even by one of its inventors [Dahl 1970]), and it formed much of the
later backbone of ADA. This led to the ubiquitous stack data-type
example in hundreds of papers. To put it mildly, we were quite amazed
at this, since to us, what Simula had whispered was something much
stringer than simply reimplementing a weak and ad hoc idea. What I got
from Simula was that you could now replace bindings and assignment
with goals. The last thing you wanted any programmer to do is mess
with internal state even if presented figuratively. Instead, the
objects should be presented as site of higher level behaviors more
appropriate for use as dynamic components.
Even the way we taught children (cf. ahead) reflected this way of
looking at objects. Not too surprisingly this approach has
considerable bearing on the ease of programming, the size of the code
needed, the integrity of the design, etc. It is unfortunate that much
of what is called "object-oriented programming" today is simply old
style programming with fancier constructs. Many programs are loaded
with "assignment-style" operations now done by more expensive attached
procedures.
Where does the special efficiency of object-oriented design come from?
This is a good question given that it can be viewed as a slightly
different way to apply procedures to data-structures. Part of the
effect comes from a much clearer way to represent a complex system.
Here, the constraints are as useful as the generalities. Four
techniques used together--persistent state, polymorphism,
instantiation, and methods-as-goals for the object--account for much
of the power. None of these require an "object-oriented language" to
be employed--ALGOL 68 can almost be turned to this style--and OOPL
merely focuses the designer's mind in a particular fruitful direction.
However, doing encapsulation right is a commitment not just to
abstraction of state, but to eliminate state oriented metaphors from
programming.
Perhaps the most important principle--again derived from operating
system architectures--is that when you give someone a structure,
rarely do you want them to have unlimited priviledges with it. Just
doing type-matching isn't even close to what's needed. Nor is it
terribly useful to have some objects protected and others not. Make
them all first class citizens and protect all.
I believe that the much smaller size of a good OOP system comes not
just by being gently forced to come up with a more thought out design.
I think it also has to do with the "bang per line of code" you can get
with OOP. The object carries with it a lot of significance and
intention, its methods suggest the strongest kinds of goals it can
carry out, its superclasses can add up to much more code-
frunctionality being invoked than most procedures-on-data-structures.
Assignment statements--even abstract ones--express very low-level
goals, and more of them will be needed to get anything done.
Generally, we don't want the programmer to be messing around with
state, whether simulated or not. The ability to instantiate an object
has a considerable effect on code size as well. Another way to think
of all this is: though the late-binding of automatic storage
allocations doesn't do anything a programmer can't do, its presence
leads both to simpler and more powerful code. OOP is a late binding
strategy for many things and all of them together hold off fragility
and size explosion much longer than the older methodologies. In other
words, human programmers aren't Turing machines--and the lesss their
programming systems require Turing machine techniques the better.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden