|
From: | David Ayers |
Subject: | Re: alloc/init - copy/mutableCopy |
Date: | Thu, 06 Feb 2003 22:57:40 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 |
Richard Frith-Macdonald wrote:
Perhaps we should abandon apple compatibility and make the abstract methods implement shallow copies too?I'm starting to think we should... Anyone writing custom collection classes that don't implement shallow copies, will be subject to breakage of code using copy/mutableCopy as soon as objects that don't implement NSCopying are contained in the array or the code otherwise relies on standard shallow copying behavior. It's not just an inconvenience for class cluster developers but for the "users" of class cluster objects when the semantics are undefined. It's just not that simple to say "the exact nature of the copy is determined by the class" when the API suggests copy/mutableCopy are to be used to transform between mutable an immutable versions. To not rely in shallow copies for copy/mutableCopy constrains the usefulness of these methods needlessly. I think GNUstep can take the lead here, and just maybe Apple will follow suit. But most likely not because we did it, but because hopefully Apple developers will kindly inform them of the implecations.
Anyway, when we use our own classes explicitly (e.g. GC(Mutable)Array) I think it's perfectly fine to assume copy/mutableCopy to be shallow. We just need to be sure that any arrays passed to us are converted to our classes before we send copy/mutableCopy, which in GDL2 and GC(Mutable)Array should generally already be the case.
Cheers, Dave
[Prev in Thread] | Current Thread | [Next in Thread] |