Re: A CoreData Limitation?
Re: A CoreData Limitation?
- Subject: Re: A CoreData Limitation?
- From: Bob Ippolito <email@hidden>
- Date: Wed, 18 May 2005 18:42:57 -0400
On May 18, 2005, at 6:02 PM, Raffael Cavallaro wrote:
On May 18, 2005, at 4:31 PM, Shawn Erickson wrote:
One way to think of it is that in your schema you should model not
only your application data but also how its structure could be
modified at runtime (just another piece of data to model). In
other words don't add a property to an entity (aka column to a
table) in your schema at runtime instead define your schema such
that you can capture that additional data and relate it as needed
(could be a simple as table that captures named or unnamed
attributes that can be related to other objects in the schema).
Of course how flexible your schema is needs to balanced against
how complex you want it and how likely schema changes are, etc. It
isn't an exact science.
This last bit (not being an exact science) is why greater
flexibility to change schema would be desirable. I was simply
noting that as it now stands, significant changes to ones data
model are likely to necessitate changing one's schema. This will of
course not be doable at runtime given Objective-C's current
inability to unload classes.
The ability to unload classes isn't really a big deal, you can
replace the implementation of methods using objc_classAddMethods
(runtime categories, basically). The only thing you can't change is
the layout of the object, but you can always work around that with
indirection (by including "ivars" in an out-of-object map table,
using a dict to hold "ivars", etc.).
With PyObjC, we allow for reloading (but not unloading, of course) of
classes so long as the ivar layout stays the same. Unless explicitly
stated otherwise, the "ivars" are in the Python's instance
dictionary, so changing them is of no consequence to the Objective-C
runtime. The instance layout remains the same.
The problem really is that such things are Hard (to develop and
debug) and Ugly (because the language doesn't really support it),
especially when using a compiled language like Objective-C which
isn't very good at 'fix and continue' in the first place. It's a
special bolted-on hack that only "works" when using Xcode. If it
were done reasonably well, I'm sure they'd have considered making the
APIs for partial compilation and code injection/replacement public :)
-bob
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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