On 2013-06-24 10:04:01 +0000, Jacob Carlborg <d...@me.com> said:
Regarding this syntax:
void insertItem(ObjcObject object, NSInteger value)
[insertItemWithObjectValue:atIndex:];
Is it possible and good to replace it with some UDA?
We could use an attribute. But I don't think it would be possible to
use an UDA. Currently the compiler doesn't know anything about a
particular UDA, all UDA's are treated the same. It it's either a built
in attribute or an UDA. Doing something in between would be a lot
harder.
Not necessarily. There's a couple of Objective-C classes that get
special treatment by the compiler (identified by a pragma). One could
do the same for an UDA so the compiler would know where to get that
value. I'd surely have implemented it as an UDA if such a thing existed
at the time.
Perhaps we should use a string UDA. ;-) (joke)
It seems contain some different things/syntax. I don't know how much
Walter&Co will appreciate it.
I would say that it's very little new syntax, surprisingly. But
semantically there's a lot of new stuff. But the core things are just
the same as with extern (C), making D ABI compatible with another
language, Objective-C. I think that this is mostly is a non-breaking
change.
It indeed is an additive and non-breaking change.
All new keywords are prefix with two underscores, which is reserved by
the compiler. A lot of stuff only apply for classes/methods declared as
extern (Objective-C).
* extern (Objective-C) - I wouldn't really consider this new syntax
* [foo:bar:] - New syntax. Does not have to use this exact syntax but
the functionality it provides is essential.
* Constructors in interfaces - Not really a new syntax. Just allows an
existing syntax to be used in a new place.
And it's only allowed in extern (Objective-C) interfaces because it
does not make much sense for D interfaces.
* Foo.class - I guess this technically is new syntax. The only thing
making this new syntax is the use of keyword. I we really don't want
this we could rename it to __class or similar.
It is a new syntax. This "function" needs special semantic treatment by
the compiler because it returns an object of a different class
depending on the type or object you're calling it on. It also mirrors
the method named "class" in Objective-C. Given these data points, it
seemed appropriate to use the class keyword, which hints at the
compiler magic. Hence why I tweaked the syntax to allow ".class" on
Objective-C classes and objects.
* __classext - Not implement yet, so that's up for discussion
* String literals - No new syntax. Just an implicit conversion added
I'm particularly proud of those string literals. They're way cleaner
than their Objective-C counterparts. :-)
* BOOL __selector(NSString) - New syntax. Kind of essential to have.
Those too are better than their Objective-C counterpart too as they
carry the argument and return type, making them less error-prone.
* Foo.protocolof - Not really a new syntax either. I don't think this
is as essential as the other features.
It gives you the pointer for protocol (interface) Foo. You need that if
you want to check at runtime if a class conforms to this protocol (or
implements this interface in D parlance).
* @IBOutlet and @IBAction - Not implemented. This could possibly be
implemented as dummy UDA's.
* Blocks - Not implemented. I'm wondering if we could use the delegate
keyword for this. If a delegate is marked as extern (Objective-C) it's
a block. Or that might perhaps be confusing.
Blocks are reference-counted and don't share the two-pointer layout of
a delegate. I'm not sure it'd be wise to call them delegates. But this
needs some more thinking.
Finally, there is a couple of features that were added to Objective-C
since then that should be added to the todo list to keep feature
parity. Some of those, if implemented right, could benefit the rest of
D too. For instance: ARC (automatic reference counting) which is
becoming a must in Objective-C.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/
