Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: Chris Hanson <email@hidden>
- Date: Fri, 16 May 2003 09:01:10 -0500
On Friday, May 16, 2003, at 01:16 AM, David Cittadini wrote:
With regards to generics, I have found the feature very useful to (a)
type collections - this guarantees the collections are of a certain
type
Hold it right there. Collections *are* types. This is the central
design flaw of the STL, assuming that the type of the objects in the
collection should propagate to the collection's type.
Many of us use heterogeneous collections a *lot*.
without having to programmatically check all the time and (b) cutting
down on coding time as I don't have to create lots of different
methods for different parameter types.
Why do you have to do this? Using Objective-C's dynamism properly cuts
down on coding time far more than crutches to make dealing with strict
compile-time types easier.
With regards to method overloading, I thought it may be useful to be
able to say:
-(int)doSomethingWithFoo:(Foo*)y;
-(int)doSomethingWithFoo:(int)y;
With method overloading the compiler could resolve most of the
parameter type issues without me having to create different method
names just because the parameter type is different.
But in both cases, you're telling the receiver to doSomethingWithFoo:.
Objective-C is an object-oriented (i.e. dynamic) language; this means
you program in it by sending messages to objects. Why would you think
something different should automatically happen based on whether you
include an int or a Foo* as the argument in that message expression?
If you want something different to happen, send a different message.
Simple, clean, elegant, and doesn't start us down the path of
productivity-constraining compile-time type enforcement.
-- Chris
--
Chris Hanson, bDistributed.com, Inc. | Email: email@hidden
Custom Application Development | Phone: +1-847-372-3955
http://bdistributed.com/ | Fax: +1-847-589-3738
http://bdistributed.com/Articles/ | Personal Email: email@hidden
_______________________________________________
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.