Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: Simon Stapleton <email@hidden>
- Date: Fri, 16 May 2003 20:47:21 +0200
David Cittadini <email@hidden> wrote:
Rants are good :-)
But should not necessarily be taken to be majority opinion ;-)
At the moment Objective-C++ is a bit of a half-way house
Indeed. Half way between ObjC and C++. Any other way would be to
favo[u]r<1> one language over another.
and really doesn't fully suit anyone.
I disagree. Suits me perfectly fine, TYVM, in the rare circumstances
where I actually feel the need to struggle with C++<2> rather than
doing high-performance stuff in plain ole 'C'
However, it could be
interesting if Objective-C++ was an Objective-C version of C++ rather
than being a half way thing.
Again, I disagree. ObjC and C++ are pretty much incompatible, IMHO.
Obj-C++ keeps them nicely separated. I like it.
<snippage>
If I override alloc and allocWithZone how does a developer know not to
instantiate my class? With abstract classes the compiler tells the
developer that the class cannot be instantiated. If I override alloc
and allocWithZone the developer will only know it cannot be used when
the program is run. Doesn't seem like a good way to build sold
"public" code to me. Without some form of abstract class the developer
has to rely on documentation in the headers. Big ask for a lot of
developers really....
If your developer is lazy enough not to...
a: read the bloody documentation so they know not to do it
b: test their code <3> and find the exceptions at runtime
... then they deserve everything they get, simple as that.
With regards to method overloading, or should it be
select-selector-by-name-and-parameters, if Objective-C is supposed to
be simple and elegant which of the following calls looks simple and
elegant:
Option 1
[self drawWithFloat:value];
[self drawWithFoo:fooValue];
[self drawWithInt:intValue];
[self drawWithWhatever:whateverObject];
Option 2
[self draw:value];
[self draw:fooValue];
[self draw:intValue];
[self draw: whateverObject];
Option 2 looks more simple and elegant to me. It seems overly complex
that the selector name has to have all this extra information in order
to make sure that the right selector gets called just because the
parameter type may be of a different type. I just want to "draw" and
the runtime can determine what to call depending on the parameter type.
Surely option 2 feels more dynamic, which Objective-C is supposed to
be.
Yes, and it is (more dynamic).
For the above example, if we allow sending ints as [NSNumber
numberWithInt:intValue], we can implement the public interface of your
-draw: selector as just that. The frantic paddling under the water
which dispatches to the relevant sub-selectors remains completely
invisible to the user of your class. s/he simply sends -draw: with an
object, and 'shit happens'. Stick the sub-selectors in a private
category, and nobody <4> need be any the wiser
Your example, however, is contrived. In real life, the number of cases
that I've come across where one has both 'C' atomic types and objects
that one wishes to send to a similar method (i.e. where you can't just
type as id) are microscopic <5>, and it's unlikely that the creation of
an NSNumber is really going to hit performance. And if it does: simply
make the primitive method(s) public. id is yor frend.
In summary, I like ObjC exactly as it is. Namespace support might help
sometimes, but having recently had to fight with code where the
declarations of routines looked something like
std::vector<std::pair<void*, std::vector<long> > > all_objects (); <6>
or worse, I found myself wishing for the implicit simplicity of (id),
and bugger the namespaces.
Simon
<1> And that's me, favo[u]ring English English...
<2> STL, actually, coz it saves me some time
<3> insert obligatory comment on how Sen:te's OCUnit rocks mightily here
<4> `class-dump` users excluded
<5> OK. I hit it once. When interfacing, oddly enough, to C++ code.
<6> Actual cut and paste of a real example
--
AppleCare. Now _there's_ an oxymoron for you.
--
PGP Key Id : 0x50D0698D
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.