Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: David Cittadini <email@hidden>
- Date: Fri, 16 May 2003 23:22:47 +1000
Rants are good :-)
I agree with the concept that Objective-C should not be "polluted", in
much the same way that C has been kept relatively simple over the
years. However, there is this thing called Objective-C++. Objective-C
extends C and therefore how about the idea that Objective-C++ should
extend C++. C++ is different from C and therefore maybe Objective-C++
should be different from Objective-C. In this way people could choose
which is suites them. In this way Objective-C++ could fully support
namespaces, templates, method overloading etc and Objective-C could
stay as it is. At the moment Objective-C++ is a bit of a half-way
house and really doesn't fully suit anyone. However, it could be
interesting if Objective-C++ was an Objective-C version of C++ rather
than being a half way thing.
I agree that classes names should follow a good naming scheme.
However, namespaces/packaging are a quite useful for grouping classes
or like functionality. Interestingly, Project Builder supports
"groups", which most people seem to use. Seems to me that this is used
because Objective-C does not support namespaces/packages. Interesting
that the IDE it used to partition code instead of having something in
the language itself. Maybe, once again, Objective-C++ can support
namespaces but not Objective-C.
Templates are an implementation of a concept. Generics, as a concept
can be quite useful. Interestingly, Java 1.5 will introduce generics
without some of the pain of C++ templates.
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....
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.
David.
On Friday, May 16, 2003, at 05:05 PM, Jeff Disher wrote:
Why does everyone insist on polluting the Objective-C language so
much? None of what anyone has asked for in this thread or the similar
thread on Omni-Dev a while back would actually add power to the
language or any other meaningful qualities.
The problem is that people want Obj-C to be C++. I don't understand
this issue and I think that you would realize that none of what you
are referring to is needed if everyone decided to learn Obj-C
paradigms instead of trying to shoe-horn C++ paradigms into it. If
you want something ugly to code in that badly, use Obj-C++.
Sorry for the rant but these threads are becoming a real annoyance to
me, lately.
As for these suggestions:
a) useful in concept but a good naming scheme (like the prefixing in
the API) is equivalent and means that you don't have to add additional
stuff to the language
b) this is useless to Obj-C. Claiming that this is needed usually
means that you are trying to write C++-ish code in Obj-C. There are
issues with templates (compiler brokenness because they are so damn
odd as well as huge binary bloat, for example) which do not occur in
the OO solutions used in Obj-C which are inherently superior
(although, admittedly, often not quite as fast)
c) There is no need for a way of specifying something as abstract.
You simply override alloc and allocWithZone: to return nil if ([self
isEqual: [<class name> class]]) else return [super alloc]
d) "Method overloading" is a bad term here, IMHO, but it is not really
needed since part of the idea is that one makes the selector describe
what the objects are. This is essentially what you want the compiler
to do for you but it becomes difficult to define what you want to see
happen when every object should just be (id). Although potentially
useful for primitives, I don't think it would actually be much use in
actual practice. You have to remember that in Obj-C methods should be
descriptive since it is very english-like and that is part of its
power.
I am very puzzled by this drive to make everything into C++. I sure
hope that none of these changes are actually implemented since they
seem to exist purely to complicate a very simple and elegant language.
Remember that C++ is referred to as "an octopus made by nailing extra
legs onto a dog" and I would hate to see Obj-C become something
similar.
Sorry, I just felt the need to state my views on this since this issue
keeps coming up,
Jeff.
On Friday, May 16, 2003, at 12:04 AM, David Cittadini wrote:
Is there anywhere to monitor or suggest changes to the Objective-C
language? For example, I am interested to know if one day
Objective-C classes will support:
a) Namespaces/packages.
b) Generics/parameterized types.
c) Abstract classes, or at least some way to enforce that a class
cannot be instantiated directly.
d) Method overloading.
I know that Objective-C++ provides this support but only if you are
using C++ classes. I am interested if the above will be supported in
"native" Objective-C classes. I know that people will have lots of
for-and-against arguments for the above but being a simple programmer
some of the above would be very useful.
Thanks, David.
_______________________________________________
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.
Jeff Disher
President and Lead Developer of Spectral Class
Spectral Class: Shedding Light on Innovation
http://www.spectralclass.com/
_______________________________________________
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.