RE: Convenience Methods
RE: Convenience Methods
- Subject: RE: Convenience Methods
- From: Jeff Laing <email@hidden>
- Date: Wed, 26 Sep 2007 13:15:01 +1000
> But you are still missing the point of why you'd want it to be
> declared to return id. Even though an NSMutableString is an
> NSString,
> you want to be able to write
>
> NSMutableString *string = [NSMutableString stringWithXXX: ...];
>
> If the method were declared to return NSString *, the compiler would
> warn you about an assignment from a distinct Objective-C type.
I understand exactly what you are saying.
But as far as inheritance contracts go out in OO land, I would *expect* that
[NSMutableString stringWithXXX: ...]
would return a *non*-mutable string since thats the contract that its
superclass establishes, and that NSMutableString does not redefine, at least
not that I can see.. Except that NSString does *not* establish that
contract, it cops out and returns 'id' - a clumsy implementation detail
hiding out in interface land.
The problem here is with the 'isa' part of inheritance. The definition of
NSString is 'a datatype that cannot be edited'. How can NSMutableString be
a *subclass* of that definition? In my opinion, the method I call should
be:
[NSMutableString mutableStringWithXXX: ...]
because that makes it clear that I want the method defined in
NSMutableString, not the inherited one from NSString whose implicit
interface contract only returns non-mutable objects.
We're really straying well into "well tough, thats how it was defined" land
and I understand that. But just because poor choices were made when setting
up NSString, that does not mean that its good form to propagate them into
your own code, especially since no-one ever sets up mutable and immutable
variants of their own classes. The whole 'should I return id or myclass*'
discussion really does hinge on that, in my opinion.
Early on, I wondered why 'const' never gets used in Objective-C. Presumably
because even an operation that would be const in other systems (adding it to
an array) results in the object itself having its retain count incremented
(which is an implementation detail of the array, not the object). The
mutable/immutable differentiation strikes me as a clumsy attempt to resolve
that problem, but it doesn't get there. In my opinion. Which may well
differ from yours.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden