Re: KeyValue Observing rant
Re: KeyValue Observing rant
- Subject: Re: KeyValue Observing rant
- From: mmalcolm crawford <email@hidden>
- Date: Mon, 26 Apr 2004 08:29:16 -0700
On Apr 26, 2004, at 3:19 AM, Michael Keller wrote:
What really worse about it is that one (ore more) Apple engineers
stated that they make a "clever" use of Objective-C by posing a
NSNotifying_nameOfOriginalClass when an instance of original class is
being observed.
Well it saves two lines of code in every set-accessor, thats seems to
be fine firsthand.
That is a fine demonstration of how flexible Objective-C is.
But one of those "little" drawbacks is, that so basic things like
-description won't work anymore.
Was there ANY quality assurance at Apple before releasing this?
Yes, there was.
I'm not ranting because they forget to call the original class
-description method. This would be an easy fix (if they choose to do
it).
But I'm ranting because this hidden posing or on-the-fly changing of
the isa is not documented and it limits other code (like plugins)
doing it too.
It is documented here:
<
http://developer.apple.com/documentation/Cocoa/Conceptual/
KeyValueObserving/Concepts/KVOImplementation.html>
Given also the lack of "delegate" patterns within the NSController
subclasses leads me to the conclusion that these classes are far
sub-Apple standards because
PROGRAMMING IS ABOUT CONTROL.
Programming is about being productive. For most people, revisiting
existing code to add two lines is tedious. You are given control: you
are welcome to disable isa-swizzling:
<
http://developer.apple.com/documentation/Cocoa/Conceptual/
KeyValueObserving/Concepts/AutoVsManual.html>
As the developer I want to and must know and control whats going on.
How "clever" is it to loose this control? Just for saving two lines of
code?
Did they at Apple thought this is "clever" use of the Objective-C
runtime? It seems to me that the guy who designed this wanted to show
us how "clever" HE is...
Many developers find that "giving up control" allows them to
concentrate on the important and interesting parts of their application
-- the encapsulation provided by object-oriented programming yields
significant rewards. Apple could have left everyone to re-implement
their accessor methods, but instead invested time and effort into
making life easier for the majority -- whilst also giving flexibility
to allow the minority to do things their own way.
I can only hope that Apple will change this braindead NSNotifying_
subclassing before its too late. That will break some existing
software but it's no effort to change the affected products source.
Having back the control is worth the change.
As noted above, you already do have control. You also have the control
not to use the technology if you find it unsatisfactory. And you are
free to submit suitable bug reports.
For the benefit of those already using the technology productively, it
is reasonable to assume that the feature will not be removed.
mmalc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.