"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