On 2013-06-27 05:35:11 +0000, Timothee Cour <thelastmamm...@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.for...@michelf.ca
http://michelf.ca/
