Re: ADC Core Data article
Re: ADC Core Data article
- Subject: Re: ADC Core Data article
- From: Marcel Weiher <email@hidden>
- Date: Sat, 9 Apr 2005 01:20:36 +0100
On 8 Apr 2005, at 16:17, Shawn Erickson wrote:
On Apr 8, 2005, at 7:52 AM, Philippe Mougin wrote:
why is this default interface for managed objects something that
is dictionary-oriented instead of object-oriented?
The definition of object-oriented or object appears to be (and is)
a rather subjective thing...
Well, I would think the man who coined the term might have some say
on this...
having accessors can been seen as exposing what is in an object
which some consider to be very much unobject like
...and he says he cringes every time he sees a naked accessor. And
he provides very good/sophisticated reasoning, which I don't think
can be dismissed as just a subjective thing, both due to the force/
logic of the arguments and due to the position of the man presenting
them. Yes, I am talking about Alan Kay. I heartily recommend The
Early History of Smalltalk for some of these thoughts, but you should
probably be prepared to spend a bit of time on it.
(one very small step from a structure, yeah yeah I know you inject
logic in accessor, etc. so they don't really have to expose the
internals) similar things can be said about NSManagedObjects
interface, and on and on.
It goes even further down that route, yes, back to pre-OO days (and
yes, I do realize that all this is implemented using OO). I see all
the "magic" that can be made to happen this way, and sure it's cool,
but quite frankly I am not convinced the magic is something that
really pays off in the long run, not that there isn't a part of me
that finds the magic very appealing (shiny things...*g*)
Quite frankly, my last 15 years in the biz have convinced me that
code should strive as hard as possible to be as *non* magical as
possible, as simple, obvious and plain *Duh* as it can be. Of
course, code should also strive to be as "little" as possible. These
two goals often appear to conflict, but I think that truly good
solutions show themselves by achieving both, usually by finding a
novel way of compactly expressing the original *intent*. (And if you
can find a way of achieving that, some cleverness in the
implementation may be excusable, as long as it's well hidden).
One of the issues with magic is that, well, it's "magical", so there
is a lot of stuff going on behind the scenes that is wonderful when
it's working, but almost impossible to untangle when something goes
wrong, making it a nightmare for maintenance programming/
programmers. In effect, in order to find/fix problems, you have to
fully understand the working of the magical bits, which can result in
having to effectively reverse-engineer them, and this can be more
difficult/time-consuming than actually writing that code in the first
place. Furthermore, when the magic goes wrong, it can go wrong in
quite spectacular ways.
Cheers,
Marcel
_______________________________________________
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