Stuart MacKay wrote:
>(..more on copying EOs..)
>I get a copyWithZone exception thrown as the NSDictionary attempts to copy
>the session login object.
Right - NSDictionary copies keys and retains the corresponding objects, which
makes sense in terms of mutability/immutability. You don't want other people
change your dictionary keys behind your back just because you used a mutable
object.
>Any ideas as to what the root cause is in EOF (other than "don't copy EO's")
>and any suggestions as to possible workarounds ? The only solution I've seen
>from the archives in to override copyWithZone: so that it implements the
>method with [self retain] but that strikes me as somewhat unwise.
The -retain workaround might be misleading to novices, and maybe even
dangerous in the long run; AFAIK its only 'real world' purpose is to have EOs
as keys in dictionaries. This requires you to only use the faked copy method
for this purpose and nowhere else. That's what I meant with 'if you know what
you're doing'.
The real problem with the otherwise fine and very flexible copy/mutableCopy
scheme and EOs is that EOs are mostly mutable by default, i.e. there's no
immutable Customer class with all the values and read-only accessors, and
another MutableCustomer subclass that can have its attributes set.
Might be worthwile to explore - because then you could implement -copy and
-mutableCopy the way they usually work, i.e. -copy as simple referential copy,
-mutableCopy as cloning by allocating a new instance etc. If all else fails,
just implement -copy as usual (creating and filling a new instance) and don't
bother to do the mutableCopy, or just stub to -copy. If you automate this in
a common EO superclass (by introspectively looking at the EOs attributes via
its classDescription and takingValues:forKeys:) make sure you properly take
care of the primary key(s) which should or must not be copied, depending on
your setup and/or the class. EOF knows where to get new pks, so let it do
what it wants to.
Am I making sense? If not, don't hesitate to ask again.
regards,
Holger
