Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!)
Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!)
- Subject: Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!)
- From: "Louis C. Sacha" <email@hidden>
- Date: Fri, 4 Jun 2004 10:59:40 -0700
Hello...
I'm not sure if you saw my post regarding the documented Apple
rationale of why copy works the way it does for the existing Cocoa
classes (it ended up in the "Ugly bug in Foundation, beware!" branch
of the thread, towards the beginning). Apple describes the general
rationale for implementing copy for any particular class (in terms of
whether the class is implemented with by value or by reference
semantics) here:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/HowToImplCopy.html
In terms of your other questions, I think that it is more a matter of
a class by class (or even instance variable by instance variable)
decision about whether something should be reference based or value
based.
The collection classes in Cocoa are defined to work in a specific
way, and have a relatively clear "contract" regarding how they work.
While some people disagree with how NSDictionary and NSArray are
implemented, the way that copy is implemented for those classes is
"correct" in terms of their "contracts".
Some people consider the implementations of NSDictionary and NSArray
to be "wrong", but if they were implemented in another manner it
wouldn't be any more "right". If people are looking for a different
implementation of arrays or dictionaries, then they should be using
different classes that have the implementation that they need.
So, I would say that it would be a very bad thing if all the Cocoa
collections were converted to be value based. If all of the
collection classes were implemented as value type classes, it would
only exchange the set of circumstances when the class worked well
with the set of circumstances it was poorly suited for.
The best solution would be for Cocoa to include separate classes with
the same interface but differing in whether they are reference based
or value based, for example NSArray and and a hypothetical (and
perhaps poorly named) subclass NSValueArray. Then the developer could
choose the best implementation for what they are trying to accomplish.
If Cocoa doesn't contain the exact implementation needed, there are
other options:
1) write your own
2) find someone else's implementation
3) file an enhancement request for Cocoa to include a class with that
particular type of implementation
The current implementations are unlikely to change in any major way,
so making an enhancement request for a new collection class/subclass
with the desired implementation is bound to be much more productive
than asking for the existing collection classes to be changed.
Louis
In the case of a Cocoa collection like NSArray, are you saying that
using by-value semantics for -copy would be wrong because
-insertObject:AtIndex: (amongst others) uses reference semantics, or
are you saying that it would be wrong to re-design NSArray to adhere
fully to by-value semantics due to the by-reference nature of
Objective-C? In other words, where's the inconsistency: the interfaces
of the class to one another, or the class design Ondra is expecting and
the language it is in? Or between different classes? Or all three?
I'll accept the first easily, but need more convincing of the
class-versus-language conflict, if someone is willing. If Cocoa were
completely re-written with by-value semantics, would that be "bad"? Is
there an inherent technical (vs. philosophical) problem with using both
by-value and by-reference semantics if the difference is clear and
logical? All that really matters is that the contract is adhered to,
surely? Does Objective-C make some contractual promises in fact
impossible?
Various arguments keep throwing out the bon mots (and the same ones)
instead of making a complete argument. Perhaps said argument exists
elsewhere and is accessible? (Forgive me if it's been posted in the
past and I missed it.)
--
Brent Gulanowski email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.