On 2013-06-26 13:07, Sönke Ludwig wrote:
I agree, it will only influence tools that include a parser. Few syntax
highlighters parse the code (although *some* do), so this was probably
not the best example.
Absolutely, some even do semantic analyze. Example, the syntax
highlighter in Eclipse for Java highlights instance variables
differently from identifiers. Don't know if there's any syntax
highlighters for D that do this.
Naively I first thought that .class and .protocolof were candidates for
__traits, but actually it looks like they might simply be implemented
using a templated static property:
class ObjcObject {
static @property ProtocolType!T protocolof(this T)() {
return ProtocolType!T.staticInstance;
}
}
So what would ProtocolType do? I think I need to look at the
implementation of .class and .protocolof. In Objective-C there are
runtime functions to do the same, I don't know if those would work for D
as well.
That's of course assuming that the static instance is somehow accessible
from normal D code. Sorry if this doesn't really make sense, I don't
know anything of the implementation details.
The __selector type class might be replaceable by a library type
Selector!(R, ARGS).
Hmm, that might be possible. We would need a trait to get the selector
for a method, which we should have anyway. But this uses templates
again. We don't want to move everything to library code then we would
have the same problem as with the bridge.
It would also be great to have general support for
implicit constructors and make string->NSString and delegate->ObjcBlock
available in the library instead of dedicated compiler special case.
Since strings and delegates are already implemented in the language,
would it be possible to add implicit conversions for these types in the
library?
Not sure about constructors in interfaces, they seem a bit odd, but
using "init" instead and letting "new" call that is also odd...
Using "alloc.init" would be more Objective-C like and using "new" would
be more D like.
You already mentioned @IBAction and @IBOutlet, those can obviously be
UDAs, as well as @optional and other similar keywords.
The compiler will need to know about @optional. I don't think that the
compiler will need to know about @IBAction and @IBOutlet, but if it
does, there are a couple of advantages we could implement. @IBOutlet
only make sense on instance variables. @IBAction only make sense on
instance method with the following signature:
void foo (id sender) { }
Possibly any Objective-C type could be used as the argument type.
Maybe it's possible like this to reduce the syntax additions to
extern(Objective-C) and possibly constructors in interfaces.
I'm open to suggestions.
I don't mean the additions as a whole of course, but each single
language change vs. a library based solution of the same feature ;) In
general this is a great addition from a functional view! I was very much
looking forward for it to get back to life.
Great. It's just a question of what is possible to implement in library
code.
--
/Jacob Carlborg
