On Oct 13, 2009, at 3:17 AM, Jon Hull wrote:
You don't need proxies or NSProxy for this. You can just use a
delegate. Off the cuff, I might consider implementing a protocol
on your immutable objects for methods like "currentLocation" and
"currentPlayer" which vector through a semi-global context object
not unlike the app delegate. Then you can use keypaths to
naturally write currentPlayer.name and so forth. NSProxy is
unnecessarily heavy weight for simple delegation. They use memory
too, ja know. And the semi-global context allows you to avoid
making all your objects larger. You might even model the "current
state" as a formal entity. That buys you change tracking, undo,
multi-writer conflict resolutions and the ability to easily
persistent and search for it. It also allows other managed objects
to work with it naturally.
Hmm... something to consider. The proxies do allow some powerful
runtime state effects. The currentLocation was just a simple (and
often used) example, but it is easy to have proxies which represent
"The sister of the person I am currently talking to" or the location
of that person or the item which that person holds in their hand.
They can also be used to represent groups of characters. This is
very powerful, and has come in very useful. Still, it might be
possible to get the same functionality in another way.
Okay. Typically the "Cocoa" way of doing that is by name and using
keypaths instead of by pointer value and NSProxy.
and then call off to the manager with the id whenever they need
to run an event. Inside
the manager I would either call off to a small sql database with
blobs
holding freeze-dried (keyedArchiving) objects & an id column,
not a great plan. No searching into blobs, no partially loading or
saving the larger freeze dried objects.
hmm... The largest blob would probably be an object with an array
of 20 or so pointers/ids. Not sure I need to search into them...
mostly I just need to grab them by id.
I had considered just using core data for everything, but as I
mentioned in a previous post, I *need* to have consistently ordered
arrays of these immutable objects (which can be in multiple places
in a single array, and can be in multiple arrays). This is
apparently difficult using core data :-(
It's not difficult, although it is a bit tedious. Ordered
relationships require you model the join table between two entities
yourself (for many-to-manys), and add an ordering attribute. For one-
to-many, you can put the ordering attribute on the destination entity
(no join table necessary).
Although, now that I think about it, perhaps I can store *just* the
array of ids as a binary property, and have everything else defined
in the entity. I will have to do some experiments.
Yes, you could do that.
Also, you could do that trivially with Core Data and just be done.
Do you mean store the blobs in a core data managedObject instead of
a SQL database?
yes
or avoid the blobs entirely using core data?
Probably
Unfortunately, it sounds like you don't have a ready alternative
besides to spend a considerable amount of your own engineering
resources. You'll have to decide if learning Core Data, and tuning
your app performance fits within your schedule requirements, and
whether implementing, debugging, and tuning all this yourself will
really take any less time.
You might consider mocking up a Core Data version over a few days
and seeing how far you get.
Yes, I think I will try that.
Any advice on how to handle the 2 different types of graphs
mentioned in my earlier post? Ideally I should have 2 files. One
holding the event tree and one holding the rest (i.e. the stuff that
changes). They main problem there is that they have connections
between each other (e.g. an event might take a location or character
as a parameter)
Just create two stores and add them to the same
NSPersistentStoreCoordinator. The connections between them can be
represented via keypaths (bound dynamically) or persistently by
stashing the objectID's URI away and materializing it in a transient
relationship in -awakeFromFetch
- Ben
_______________________________________________
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
