Re: gnustep/base modifications for OSX

[David Ayers]

Hello Richard,

I've also been biten by this a lot, and I've been thinking about it very 
hard, but I don't think it's that "simple" as you suggest.  In fact I 
really don't understand how Apple code is working under these conditions.

We have a state of undefined semantics (deep/shallow) for copyWithZone: 
(and therefor copy) and mutableCopyWithZone: (and therefor 
mutableCopy).  It might be well defined if you have simple collections 
that you can require "applications" (or in this case libraries) to use 
initWithArray:copyItems:, which will send "copy" to the contents, if the 
flag is YES.  But if the contents are again collection classes then you 
just simply have undefined behavior (depending on the concrete class) 
for the contents.

The *bug* is that you can't really allow undefined semantics for such 
fundamental and in this case recursive messages for a class clusters.  
(I dare say this breaks object orientation.)

I've also been thinking about this a lot but haven't come up with a 
solution that would (a) solve the problem and (b) be compatible with the 
arbitrary behavior that OS X seems to introduce.  In fact I would say 
that if OS X apps don't assume anything, that we do find a consistent 
behavior in favor of being compatible with the "undocumented" behavior 
of certain subclasses.  In practice this is not going to work either 
though, unless we never collections within collections.

We should at least give it alot of though.  I really believe that Apple 
has broken something here.  Maybe it would be worthwhile to file a bug 
report showing this.

Cheers,
Dave


Richard Frith-Macdonald wrote:

> I've changed that (for consistency with our other classes) ... but 
> it's not a bug as such.
>
> The MacOS-X release notes on copying containers specifically say you 
> should *NOT* assume anything about whether a copy is shallow or deep 
> ... so an application which depends on a specific behavior is 
> broken!   In particular, some of the abstract class copy method 
> implementations differ from those of the concrete classes!
>
> If an application needs a specific behavior, it should not copy an 
> array, but rather should use retain, or should create a new array and 
> initialise it using -initWithArray:copyItems: setting the flag to say 
> whether items should be copied or merely retained (the same applies to 
> dictionaries and sets).