"Modern" ObjC syntax causing possible semantic problems?
Kenneth C. Dyke
kcd at jumpgate.com
Fri Jul 25 21:56:27 PDT 1997
One of the reasons that I really like the Smalltalk syntax for Objective C
is that it really makes things unambiguous. You always know from looking at
code exactly what is going on.
Right now Objective C allows programmers to have method names that match
instance variable names, and they don't occupy the same namespace. There is
also no possible way to confuse them.
However, I fear that the 'modern' syntax could pose a serious threat to this.
Consider the following (albeit contrived) example of a class definition
using the Smalltalk syntax:
@interface MyObject : NSObject
{
int (*someName)(void);
}
- (int)someName;
- (void)someOtherMethod;
@end
Then you could have a definition like this
@implementation MyObject
- (int)someName
{
return someName();
}
- (void)someOtherMethod
{
[self someName];
}
@end
(BTW, the above will compile with no warnings at all).
Now what happens when you have to use someName with the new 'modern' syntax?
@implementation MyObject
int someName()
{
return someName();
}
void someOtherMethod
{
someName();
// Or?
self->someName();
}
@end
It seems to me that it would now be possible to have conflicts between the
syntax for method calls and for function calls via function pointers. The
compiler has no way of knowing what you want because the syntax for both may
wind up being identical. The only way to avoid it would be to not allow
method names with the same name as instance variables, which would be a major
drag, and a restriction we don't have now.
These same problems are part of why I dislike C++. The same syntax is used
to represent many different things, even if they are different concepts.
Thoughts anyone?
-Ken
More information about the MacOSX-talk
mailing list