RE: NSObject Exercise comments?
RE: NSObject Exercise comments?
- Subject: RE: NSObject Exercise comments?
- From: "Frode" <email@hidden>
- Date: Mon, 12 Dec 2005 23:25:55 +0100
- Importance: Normal
-----Original Message-----
From: John Stiles
Sent: Monday, December 12, 2005 8:04 PM
To: Andreas Mayer
Cc: email@hidden
Subject: Re: NSObject Exercise comments?
>
On Dec 10, 2005, at 10:39 AM, Andreas Mayer wrote:
>
>
>> > > -(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.
>
>
>
> 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. At least it's
>
> uncommon and therefore confusing.
>
>
Is that so? I thought that was one of the coolest points of Cocoa,
>
honestly. You certainly still see it throughout Apple's classes.
I like message concatenations, too, and use it heavely when there is
chance to do so even if the return is a new object. You could compare
with C++ standard templates, where almost all member call returns itself
for concatenation. Unfortunately, AppKit and Foundation never return
itself except in exceptional cases. Antoher rare case beyond this is
initializers, where itself is returned.
If the returned object is immutable, then I can't see it matter whether
the returned object is itself, or whether it is a new object. If you
want to return a "mutable itself", one way could be to introduce a
mutable version of Fraction, and return a "MutableFraction*", or an
"id", or a more diligent way, return "itself", where #define itself
id...
For example, I suppose
- (NSString *)stringByExpandingTildeInPath // resolve e.g. ~/Pictures
- (NSString *)stringByResolvingSymlinksInPath // resolve e.g. /tmp
returns itself if there is no work done, otherwise a new string object.
Note the immutable return.
But in Foundation,
- (NSString *)stringByAppendingString { ... } // Cocoa implementation,
returns a new string
- (NSString *)stringByAppendingFormat { ... } // Cocoa implementation,
returns a new string
have void returns in their corresponding mutable forms
- (void)appendString { ... } // Cocoa impl. appends a string
- (void)appendFormat { ... } // Cocoa impl. appends printf-formatted
string.
Because of this, I usually use stringByAppending... instead of append...
even if this is overkill, just to have message concatenations.
Thus, one way would perhaps be to name the message in question
fractionByReducingFraction and return a new Fraction object even if this
is overkill. Then, create a subclass to Fraction, call it
"MutableFraction" and implement the mutable message "reduceFraction". I
myself would return itself instead of void.
@interface Fraction // immutable objects never changes (besides the
reference count)
{
unsigned nom, den;
}
...
- (Fraction *)fractionByReducingFraction; // return a new reduced
fraction (or itself if object is already reduced.)
@end
@interface MutableFraction : Fraction // all messages that change the
object goes here
- (id)setNominator:(unsigned)nom;
- (id)setDenominator:(unsigned)den;
- (id)reduceFraction; // reduce this fraction as much as possible
@end
In this case, it would be temptating to return itself for concatenated
message, c.p.:
[[[obj setNominator:21] setDenominator:7] reduceFraction];
(The reason for introducing Fraction and MutableFraction is also that
applciations and dynamic libraries can take advantage with immutable
object, but that's another discussion.)
Regards,
Frode
_______________________________________________
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