Re: NSObject Exercise comments?
Re: NSObject Exercise comments?
- Subject: Re: NSObject Exercise comments?
- From: Lee Cullens <email@hidden>
- Date: Tue, 13 Dec 2005 03:00:24 -0500
Andreas Mayer wrote:
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.
Not something I've read (as you say :-), but certainly a reasonable
prioritization and rational. Where Apple enumerates all the reasons for
"implementing" Cocoa with ObjC, they don't say all the reasons have top
priority in their implementation.
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).
Sounds a little like my previous reluctance to use an id return type :-)
, but that was a different context.
Instead, descriptive method names are used so that one can often
deduce the type/class of a parameter by simply looking at the code.
But as you say, Cocoa doesn't shield developers from their own
shenanigans. I know - there is only so much they can do.
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.
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
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.
Here I'd have to say it's seldom that simple anyway, but that's just my
experience :-)
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 ... :}
Well, I've had cases (in the deep dark past) where such polymorphism
would have certainly reduced the code I wrote, but not by much (not even
an offsetting amount) considering additional method code and I've
bolstered you're argument once again. Da##, I'm not doing very well
:-) Four years beats one month.
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)
My "primitive" thoughts were for at least same named consistent type
methods (having to only check that the argument type was the same)
supplied in Cocoa without subclassing/whattever. I haven't run into
the Class Clusters in ObjC you mention, so that is something else I have
to look into :-( I know it's a simple concept, but I'm still a little
shaky about protocols yet.
All in all I'd argue the disadvantages would outweigh the advantages
by far.
Given that I've bolstered your arguments more than my thoughts, I won't
contest that assertion.
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
Well, once again, you've shown me the error of my ways/thoughts so you
have not wasted your time IMO. When all is said and done (a lot more is
said than done :-), you're arguments are similar to my thoughts about
metaclasses, argument and operator overloading, and a few other aspects
of OOP I find esoteric in a practical application (not language
development) sense - but such is outside ObjC and Cocoa so let's not go
down that path. As I said before, I'm becoming fond of ObjC to a large
part because of its' simplicity.
Thanks again,
Lee C
_______________________________________________
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