>>> No one has ever been able to give me a convincing answer as to why EOF was >>> ditched in favor of CoreData. I can understand EOF, it feels >>> object-oriented and ObjC-like. CoreData is a like a plate of spaghetti to >>> my mind, very C++ like, syntaxy, and hard to get your head around ... >> >> How about this for a good reason: EOF was huge and in need of a major >> overall. >> >> EOEditingContext was three different classes lumped into one big mess. > > Heh, that's how I see CoreData: one big mess. EOF did have one major > redeeming quality: I could understand it! :) I've given up on CoreData for > now. Maybe someday I'll revisit it...
I only took a quick look at Core Data, and it didn't seem that hard to understand -- about 75% of EO with much less confusion. What did I miss that was confusing? EOEditingContext ... Well, lets see. At the bottom was EOAccess, which was in two parts. One stock, and one was "roll your own" database specific. There was no real sample code to base your work on, other than flat file -- no actual sample SQL database example. I'm assuming that's changed now. The whole "No basic DB adaptor included for any free DB other than flat files" thing kinda stank as well. Then, you had a portion of EOEditingContext designed to get stuff out of EOAccess. Then, a portion of EOEditingContext designed to edit. Then, a portion of EOEditingContext designed to provide data to the display. Then, * Two different display classes, with different interfaces, with no unifying access protocol *. It wasn't always clear what the details of routine X actually did -- the documentation was horribly lacking in places, and "determine by experimentation" is a really bad way to go. The whole object's primary key generation seemed to only be half documented. The whole "you need to know what class this row is expected to turn into ahead of time" was a problem. While "Encode the class in the primary key" was the quoted answer, there was no sample "How to" to make it work. And despite everything that was done, duplicate default primary keys could still be generated -- they were not unique enough. There were hooks to allow you to save a session state, but how to use them wasn't really well explained. At the time, A magazine (I think it was Byte) had a challenge to the three big database systems (Apple's Wo/EOF was one of them) to implement a fictional "nile.com" -- an amazon-like book seller. One of the test cases was pulling the power plug on one of the three servers, to see if there was automatic failover -- and Apple did not. And, I don't know if the "raw rows memory leak" was ever fixed -- every time you fetched an object, the raw database row was brought into memory, and never discarded. I'm assuming a database adaptor code base now exists, and now that I know of project wonder, I'm assuming that there's "specify class in the primary key" stuff in there. Heck, I'm assuming that there's a good "store/fetch list/array/other ordered collection into database" method by now. Last time I used EOF was 2001; how has it improved in 10 years? _______________________________________________ MacOSX-talk mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-talk
