Re: NSObject Exercise comments?
Re: NSObject Exercise comments?
- Subject: Re: NSObject Exercise comments?
- From: Ondra Cada <email@hidden>
- Date: Sat, 10 Dec 2005 20:11:14 +0100
Well, if we are to pursue it...
On 10.12.2005, at 19:39, Andreas Mayer wrote:
Also, it is often a good idea to use more generic method names so
that objects of different classes use similar method names for
similar functionality. Take container classes as an example: Each
container class responds to 'count', no matter if it is an array, a
dictionary or a set. This not only makes it easier to remember, but
it also allows a more abstract use. If I just want to know how many
object are in a collection, I need not care if it's an array or a
dictionary. That leads to more robust code (I can swap the
collection class without changing that code).
Agreed. Also, it is not unheard-of to widen this very polymorphism to
any object by using (something conceptually similar to) this category:
@implementation NSObject (CanUseAnythingAsContainer)
-(unsigned)count { return 1; }
-anyObject { return self; }
-(NSEnumerator*)objectEnumerator {
return [[NSArray arrayWithObject:self] objectEnumerator];
}
-(NSEnumerator*)reverseObjectEnumerator { return [self
objectEnumerator]; }
@end
> > -(Fraction *) reduceFraction
However, it is a good point because it leads to unnecessary
confusion.
That's actually the main point, I think. When I see a method that
returns an object, that object is usually a new one.
Not quite. Still, it may be worth the effort to return self in cases
when the chaining is very common: retain, autorelease being probably
the best examples. Classes which would be often parts of expressions
would benefit from that, too -- [[[a add:b] subtract:c] multiply:d]
is still much better readable and less error-prone than some
x=[a add:b]; x=[x subtract:c]; x=[x multiply:d];
(Of course this is the one case when operator overloading would come
handy, but since we don't have it at all, the point is moot :))
I know that there was a convention were the original object was
returned when ever possible, so that one could 'chain' method calls
together. But I think this is discouraged now.
Cocoa uses now a conversion "if there's nothing to return, don't
return anything", the very reason being DO: with distributed objects
which communicate betwixt threads or processes or even computers
through a network, a void return can be *vastly* more efficient than
an ignored object return.
The new convention is thus reasonable in a generic case. Though, for
a concrete class which is never intended to be used with DO nor re-
used heavily, I personally (!) would think that the convenience of
the original NeXTStep convention (i.e., "if there's nothing to
return, return self for easy chaining") should win.
Also, I'm not sure it's a good idea to alter the object in that
method. Someone may still hold a reference to it and may not expect
it to suddenly change it's value. But *if* you do, make sure to
document it clearly.
Being used to this approach with NSNumbers and NSValues, we tend to
consider these objects immutable. An explicit note in documentation,
though, should be enough, in my opinion: depends on the intended
usage, I guess :)
---
Ondra Čada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden