RE: NSObject Exercise comments?
RE: NSObject Exercise comments?
- Subject: RE: NSObject Exercise comments?
- From: "Frode" <email@hidden>
- Date: Tue, 13 Dec 2005 15:12:47 +0100
- Importance: Normal
-----Original Message-----
From: cocoa-dev-bounces+frode=email@hidden
[
mailto:cocoa-dev-bounces+frode=email@hidden] On Behalf
Of Lee Cullens
Sent: Tuesday, December 13, 2005 9:00 AM
To: email@hidden
Subject: Re: NSObject Exercise comments?
>
Andreas Mayer wrote:
>
> There are basically two approaches here. You can either add the
>
> necessary support to the implementations to accept lots of other
>
> number classes or you could just fail with a runtime error if a wrong
>
> object is passed.
>
In the simplest case I mentioned, just checking the argument for the
>
same type would be involved - is that too much overhead to facilitate
>
code reuse? That is, in the case where the polymorphism is not the
>
predominate processing (e.g. adding two vectors in a 3D renderer the
>
same method name as adding color objects). So, to give the developer
a
>
choice, maybe both a specific named method (without argument type
>
testing) and a "-(id) byAdding: (id) aWhatever;" would add more to
the
>
total code than that saved. Also, my simplest case would entail the
>
runtime error you note. I'm not an excessive minimalist, but I've
just
>
given more weight to you're thoughts %-P
You could also check that the object responds to messages at compile
time by using protocols. But this assumes that both the "vectors" and
"color" objects responds to same selector.
Just declare your protocol like an interface, then declare and define
byAdding like
@protocol My3DObjectPropertyProtocol
- (id)byAdding;
@end
- (id) byAdding: (id <My3DObjectPropertyProtocol>)whatever { return
[whatever byAdding];}
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