Re: EOF replacement
Re: EOF replacement
- Subject: Re: EOF replacement
- From: email@hidden
- Date: Thu, 21 Feb 2002 03:26:32 -0800
I think this thread doesn't belong on these lists.
I think the question of how one should make his objects persistent is
very legitimate one for a developer's mailing list. Even the wildest
Photoshop or iYounameit user one day might need an accounting or shared
contacts application and NS(Un)archiver will not help to develop such
a beast...
Well, I'm not going to prolong the thread by arguing about whether or
not the thread should be on this list. Clearly the thread is here. At
least we haven't descended into squabbling about whether or not Apple
had the right to pull the Obj-C EOF or not. :->
As someone who has actually seen NeXTSTEP running on IBM hardware and
followed and contributed to the technology for the past 12 years I am
very well aware of what it does mean to write a replacement for EOF.
Um... I've seen NeXTSTEP running on IBM hardware too; I worked on an
Intel box at NeXT. And I worked on WebObjects for years. And I think
if you're imagining writing EOF for Obj-C yourself, you're in fantasy
land. On the bright side, if you do succeed, you'll have a product you
can sell to other people for staggering sums of money. :-> Of course,
you'll have to be careful not to violate any Apple patents...
The reason why I asked my question is the fact that Apple is fiddling
with the Foundation kit for some time now: key-value coding is now part
of it, methods like inverseForRelationshipKey are showing up,
EOClassDescription and EONull made it also into Foundation... This of
course helps the AppleScript integration and makes it possible to
integrate in a nice and consistent way other languages like Ruby or
Python. But this is a huge step towards persistency framework too. It
might also mean that Apple is already working on it too. Today it is
much easier to duplicate the old EOF functionality ... just think on
what Foundation was back in 1994!
Those little snippets of EOF functionality are trivial compared to the
bulk of EOF. Having those things provided for you in Foundation will
save you a week or three of work at most. And of course you're assuming
that the Foundation implementation of those things contains everything
you will need for your EOF clone, but really, it probably doesn't.
You'll probably have to implement your own key-value coding so you can
put the hooks and search order and such in it that you need, for
example. EOF's key-value coding is a very complicated affair. I don't
believe Foundation preserved all that complexity, although I could be
wrong, I haven't looked at it recently.
I truly hope to receive more constructive comments...
I'm trying to give you constructive feedback: option number 4, writing
EOF yourself (and, as you said, fixing all the annoying long-standing
bugs and adding the features you've always wanted), is a massively
unrealistic option. It took a whole team of some of the smartest and
most capable engineers I've ever met in my career to write EOF, and it
took them years of work to do it. I guess if you have no concrete
deadline for your product, you can go off into never-never-land like
this (just don't expect to come back). But I think ideas like using and
contributing to GNU's EOF clone, or better yet, re-evaluating your
decision not to use the Java EOF, would be much, much wiser.
If you didn't want to hear people arguing against the decision you
were considering making, then it isn't clear why you asked the
question -- your mind is already made up. If, on the other hand, your
mind is still open to being changed, then please don't accuse me of
being "unconstructive" just because I'm trying to change it.
Which brings us back to my assertion that this thread doesn't belong
on this list. And with this post, I'm done; I won't be posting any
further messages on this thread to the list.
Ben Haller
Stick Software
_______________________________________________
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.