Re: NSObject Exercise comments?
Re: NSObject Exercise comments?
- Subject: Re: NSObject Exercise comments?
- From: Andreas Mayer <email@hidden>
- Date: Tue, 13 Dec 2005 06:45:39 +0100
Am 13.12.2005 um 04:24 Uhr schrieb Lee Cullens:
I wondered why not "the same as" like arithmetic methods used
"many" other places.
[...]
I'm not saying there *is* a "standards" selectivity mindset (don't
know enough to argue the point), but rather am throwing this out in
the hope of gleaning more insight into community methodologies :-)
First, please note that I am making this up on the go; there's no
(single) documentation (that I know of) that would back what I'm
going to say here ... :)
Objective-C as well as the Cocoa libraries are aiming for simplicity,
efficiency and clarity first, with functionality coming in only as a
close second. That's because you can always add any missing
functionality later without too much trouble.
For example, Cocoa usually doesn't shield developers from their own
mistakes. If you pass the wrong object you'll get a runtime error.
While it would be possible to catch those errors (through
introspection), it would be detrimental for efficiency (and arguably
even bad for correctness since some errors might not get caught in
development and slip into the shipping app).
Instead, descriptive method names are used so that one can often
deduce the type/class of a parameter by simply looking at the code.
Now lets look at your proposal.
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.
Obviously the latter wouldn't make things better at all. You couldn't
see from looking at the method name what type of parameter was needed
while the functionality would be the same as it is now.
The first solution on the other hand does incur a certain overhead on
every method call. Therefore we have to decide if the functionality
we gained is worth the tradeoff in efficiency. So, how often would
you think it is necessary (or even useful) to be able to add number
objects of different classes? Well, I can only speak for myself, but
I'm not sure I even had to add number *objects* even once; usually I
just convert to/from scalar C types and use those for calculation. Of
course I'm only working with Cocoa for about four years now ... :}
Another weak point is, that you'd be only able to support classes you
already know about. And you would end up with more or less the same
code in different classes; one implementation for NSDecimalNumber,
one for XXComplexNumber etc. Not really an elegant solution. (If
you'd really want to do something like that, I think a class cluster
might be the way to go. See
http://developer.apple.com/documentation/
Cocoa/Conceptual/CocoaObjects/Articles/ClassClusters.html)
All in all I'd argue the disadvantages would outweigh the advantages
by far.
But what, if you really *do* need that functionality?
Easy. Just add it on your own. You can always add methods to existing
classes by writing a category. That way you can decide on a case-by-
case basis if you want to include that category into your project or
not. No useless junk if you don't need it, all the functionality if
you do. :)
Hm. I feel like I'm losing focus on the topic, so I'll stop for now
and wait for comments. :-)
Andreas
_______________________________________________
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