Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: publiclook <email@hidden>
- Date: Fri, 16 May 2003 14:08:53 -0400
On Friday, May 16, 2003, at 09:22 AM, David Cittadini wrote:
[Deleted]
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....
A) Developers need to use documentation regardless of the abstractness
of a class. Unless someone wants to argue that there is no role for
documentation, I suggest we dismiss this point. There are other issues
of designated initializers, primitive methods, etc. that require
documentation.
B) What is the big deal about finding out at run-time that you are
using a class incorrectly ? Even if you don't have or don't read
documentation, surely you test at least to the extent that you know if
you are incorrectly allocating instances.
C) There is no way for an Objective-C compiler to know at compile-time
if you are instantiating an abstract class. Examine the following
code:
id ReturnInstanceOfAnyClass(Class aClass)
{
return [[aClass alloc] init];
}
Unlike C++, Objective-C classes are a run-time feature and they are
first class objects. C++ removes all classes at compile time. In
Objective-C, there are Classes may be used in any situation where
instances can be used because in concept, classes are instances of the
Class class which itself is conceptually a subclass of NSObject. Did
you know that all Objective-C classes respond to every message that
NSObject instances respond to ?
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 1 looks simpler and more elegant to me. The types of arguments
are almost always encoded in objective-C selectors. Just one example
at random:
Initializing a new NSImage instance
initByReferencingFile:
initByReferencingURL:
initWithContentsOfFile:
initWithContentsOfURL:
initWithData:
initWithPasteboard:
initWithSize:
Telling people reading the code the expected types of the arguments is
a GOOD thing. C++ gets this wrong IMHO and massively wrong when
combined with implicit type conversions and templates. Even the author
of some C++ code can not say with certainty how much code is going to
be executed just to convert types...
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.
There is a technical obstacle also. To differentiate between selectors
with the same name but different arguments, the compiler may be forced
to use name-mangling like C++ compilers. Even ignoring all the hassles
with broken binary compatibility etc. with C++ name mangling, mangling
selector names would end one of the most powerful features of
Objective-C:
In the following code, which of your -draw: methods is being invoked ?
[someObject performSelector:@selector(draw:) withObject:nil];
How about in this one:
[someArray makeObjectsPerformSelector:@selector(draw:) withObject:nil];
Name mangling destroys simple string to selector conversions and leads
to ambiguity since the types of arguments the -draw: method expects
depends on the type of the receiver, and Objective-C explicitly does
NOT know the type of the receiver at compile-time EVEN IF YOU USE
STATIC TYPING.
----------------------------
Asking for these features in particular reveals a profound
misunderstanding of the design, rationale, and idioms of Objective-C.
I used to work with Fortran programmers who were transitioning to Ada.
They wrote code affectionately called Adatran because they could not
understand that there are many ways to do the same thing even in one
language let alone in different languages and that different approaches
are "better" in different languages.
Please, I beg, don't anybody turn Objective-C into C++. Add just the
mis-feature of name mangling and see all of the consequences.
One last though, perhaps what you want in the way of abstract classes
is Objective-C protocols ?
_______________________________________________
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.