Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: Jeff Disher <email@hidden>
- Date: Fri, 16 May 2003 03:05:48 -0400
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.