Re: Future Objective-C changes
Re: Future Objective-C changes
On Fri, May 16, 2003 at 04:16:50PM +1000, 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 without having to programmatically check all the time and
This kind of thing runs counter to the spirit of Objective-C's type
system. (a) is the typical strong-typing rhetoric, typified by C++
and Java, where you rely on the compiler to check such things. If you
use good testing discipline, such type checks are just redundant.
Bruce Eckel wrote an essay on this recently, with respect to Python,
but it's equally applicable to Objective-C:
<
http://mindview.net/WebLog/log-0025>
>
(b) cutting down on coding time as I don't have to create lots of
>
different methods for different parameter types. The problem with
>
Objective-C++ is that I cannot use generics on "native"
>
Objective-C/C++ functions/methods - I can use templates within
>
Objective-C/C++ methods/functions but methods/field declarations
>
cannot contain templates. It would be nice if generic/parameterized
>
types were at least available to all parts of Objective-C++ code.
I don't understand at all. Interfaces are totally informal in
Objective-C if you want them to be; you can send any message to any
object without needing to specify a class or interface at compile
time. There's no need to parameterize interfaces at all.
>
With regards to abstract classes, it is a bit of a pain to create empty
>
methods that just throw exceptions. The problem is that the caller has
>
no way of knowing if the class is abstract or not. You have to sort of
>
instantiate it to see if it works. Wouldn't it be much nicer of the
>
class could declare itself as abstract in some way - without finding
>
out after you call it.
This goes back to the compile-time checking thing. I never use a
class without looking at documentation; it should be quite clear from
the docs whether a class is considered abstract (or a 'class cluster'
in Objective-C terms).
>
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.
This is a special case since you're using primitive and object types
for the same method. Besides, 'y' is not a 'foo' in any case, it's an
int, so you wouldn't want to name the method that way.
It may help to simplify the problem and consider a bit of history. In
Smalltalk, the above declarations would simply be:
doSomethingWithFoo: aFoo
doSomethingWithInt: anInt
Translating directly to Objective-C, you'd have:
- doSomethingWithFoo:aFoo;
- doSomethingWithInt:anInt;
or, more explicitly:
- (id)doSomethingWithFoo:(id)aFoo;
- (id)doSomethingWithInt:(id)anInt;
Smalltalk has absolutely no type declarations in methods; every method
accepts objects as arguments and returns an object (self, if not
otherwise specified). The selector indicates recommended type
information by its name, typically, although abbreviations prevail for
common selectors (e.g. where Foundation has -objectAtIndex: and
-objectForKey:, Smalltalk just uses at:).
Objective-C initially used selectors almost identical to Smalltalk's,
but OpenStep/Cocoa migrated to the current mixed method of typically
explicit types except where extensive polymorphism is possible -
consider the (id)sender pattern used for action methods in AppKit.
But this is only a compile-time check - selectors do not encode type
information. I've never found myself wishing for type-based method
dispatch in Objective-C or Smalltalk, though I certainly see the point
in Java and C++.
--
=Nicholas Riley <email@hidden> | <
http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
_______________________________________________
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.