> >> Anyway, I ended up with a graph of Objects and > methods which looks nice and consistent and -- clean! > :-) > > I'm happy with my model. And I'm certain it would benefit > from Core Data. > > > A1: A lot of beginners complain about this. A lot of > intermediate to pros recognize that the documentation > is far better than most platforms. > > That's not saying much :-)
"better than most platforms in the last 10 years", maybe. Mac OS 7 and 8 and 9 had better docs. Kronos, back in the 1970s, and NOS in the 1980s had far far better docs. So, the proper thing to do is just keep on submitting suggestions, corrections, requests for clarifications to the docs. > > The trick is, you just have to take the time to > familiarize yourself with it. Study, study, study. > This is a very large platform with a lot of powerful > technologies. "Powerful" is not a word I would use in this context. Not quite elegant, or striving to be elegant, maybe. > It's not a toy language or API by any stretch of the > imagination. But Core Data seems to be. > Finding your way around will take time. > Learning what are clearly labeled as "advanced" technologies > will require you to master the basics first (surprise!), so > give it time and study. Which "basics"? The greatest "basic" that would allow someone to read the docs and grok how to design new software making use of these frameworks would be the psychotic power to reach out to the mind of the original framework designer(s) to understand the extent and limitation (things that seem to logically follow but do not because he/they weren't thinking of them when they designed this part of the frameworks) of his POV, and the direction of development of his ideas, and the terminology used that doesn't quite mean what it appears to mean (not what it meant in other languages, libraries and frameworks you've used in the past, or in the "real world"). > > A2: All the more reason to heed the warnings and stick > to basics. Whether Core Data is a good match for your > project or not (more on that in a second) is largely > irrelevant since you have already indicated (I think - the > rambling makes this hard to say for sure) that you haven't > read the more basic technologies upon which Core Data is > built. > > No, I read the Core Data Basics chapter of the Core > Data Programming Guide, I'm happy enough with KVC and > KVO for now - at least my bindings between an > NSTableView, NSArrayController and my NSArray are fine. > So, I'm sort of OK with bindings, notifications and > delegation, although not thoroughly immersed in the > mind set. Yet. So, according to the recommended > learning path, the next step would be going through > the tutorial (which it later says, is NOT how you do > things...) > > > Therefore, your first app should use the most basic > methods. Build your data structures with dictionaries, > arrays, and NSCoder-compliant custom objects as you wish ... > then write the main container to a file. There's your > document format. Start with the basics, then move on > to the voodoo. But I've already done the object-relational diagramming of a major military logistics data warehouse (rat's nest, really), a vehicle fleet management system and other toys, and taught the techniques to others. After that, what can seem like voodoo in far simpler graphs of data in this thing that's not even tied to one full-featured relational data-base? It should be a walk in the park, a mere application of well-known principles. Only it's not. Why not? I'd advise reading the docs at least 3 times, and maybe the Objective-C 1.0 and 2.0 docs (the best of the whole lot, IMO) a couple times each. Typically, a student is expected to retain maybe 15% of what he reads the first time from a text book. In the past, I've tended to retain maybe 50% from text books and reference manuals. A good teacher answering just the right questions as they arise can bring that up rapidly. A second pass through documents written from another POV, by another author, with different holes in his presentation is also helpful. With that good mentor who's BTDT, a bright industrious study group, I'd be up to the 98% neighborhood before a 2nd pass (at which point what I had for breakfast becomes a more important factor). The OS X docs bring me down to maybe 5%-10% for a first run-through. By the time I've read a set of them 3 times, I'm finally getting up to my accustomed first-pass 50% or so. And, as someone noted, there are a lot of docs, so it often happens that between passes one or two revisions have been issued and it's time to start over. In Cyber days and VAX days and DG days and SGI Iris days, I'd be up to about 85% by the 2nd pass and have implemented the features into a couple releases. On OS 7 I'd be trying to implement features on the 2nd pass, but be making mistakes because of ignorance of the full context, and be needing to make a third pass to fix bugs. On OS X, by the 3rd pass I'm just getting up the courage to try something beyond the super-simplistic tutorial sample code, because now a lot of these things are not incremental; they're all or nothing. If you don't have every duck lined up just right, it doesn't just give not exactly the desired result, it melts down, locks up, or crashes. I have to agree with the OP. Don't jump into Core Data. Use Dictionaries, try to conscientiously make your accessors key-value compliant. Dot notation is a nice short-hand, but you're just as well off using the accessors conscientiously for a while. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
