proposal for better syntax for extern objective-C and compatibility with named argument parameters

[Michel Fortin]

On 2013-06-27 05:35:11 +0000, Timothee Cour <thelastmammoth at gmail.com> said:

> See [1][2] for related thread introducing extern(objective C)
> 
> A)
> The syntax proposed in [2] transforms:
> -(void) insertItemWithObjectValue: (NSString *) path atGreen:(NSInteger)
> anInt;
> [obj insertItemWithObjectValue:val atGreen:idx ];
> 
> into:
> void insertItem(NSString* object, NSInteger anInt)
> [insertItemWithObjectValue:atGreen:];
> obj.insertItem(val, idx);
> 
> B)
> I don't see how it handles this case:
> [obj insertItemWithObjectValue:val atGreen:idx ];
> [obj insertItemWithObjectValue:val atRed:idx ];
> 
> obj.insertItem(val, idx); //atGreen or atRed ?

If green and red are the same type then you can't use overloading and 
must come with two different function names. Here that'd be 
insertItemAtGreen and insertItemAtRed.

I agree we lose some expressiveness by shortening the names, but I 
think keeping the same function call syntax as the rest of D is 
worthwhile. If you require a special syntax for those calls then it 
doesn't integrate well with other parts of D: you can't make an alias 
to those functions nor pass them as alias parameters to templates (not 
without a custom syntax for this too), and generic code designed with D 
in mind will probably not work.

> C)
> The fact that one needs to come up with a new name insertItem is not good
> (as done in [2] ). And if we reuse the name:
> 'void insertItemWithObjectValue(NSString* object, NSInteger anInt)
> [insertItemWithObjectValue: atGreen:];'
> Then it's not DRY.

It doesn't matter much. The current design only require specifying the 
selector if you are generating bindings, and this should be automated 
anyway.

Overrides inherit the selector, and original methods get a generated 
selector (which you can get and pass around with a simple syntax). So 
unless you're writing bindings you shouldn't have to care about 
selectors at all. This is a perfectly good way to define an Objective-C 
object:

	class MyObject : NSObject
	{
		private NSString _name;

		this(NSString name) { _name = name.copy; }

		@property int name() const { return _name.retain.autorelease; }
		@property void name(int newName) { _name = newName.copy; }

		override NSString description() { return name; }
	}

The only thing telling you this is an Objective-C object is that it 
derives from NSObject. You're still programming in D, not in a special 
dialect of D meant to interact with Objective-C. That's the spirit.


> D)
> the variable list is separated from the argument name list; this makes it
> less readable with more arguments.
> 
> E)
> the only benefit of objective C's syntax (making it clear at call site what
> is the argument description) is lost.

Well, the alternative is to use a custom syntax that doesn't play well 
with other D features. It's akin to how C++ and Objective-C can both be 
used in the same file. It could be done, but that's an entirely 
different project.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/