Am 26.06.2013 12:09, schrieb Jacob Carlborg: > On 2013-06-26 10:54, Sönke Ludwig wrote: > >> I agree. Even though it may not be mentioned in books and many people >> may never see the changes, it still *does* make the language more >> complex. One consequence is that language processing tools (compilers, >> syntax highlighters etc.) get updated/written with this in mind. > > I don't think there will require much change for tools (non-compilers). > I see three "big" changes, non of them are at the lexical level:
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. >> This is why I would also suggest to try and make another pass over the >> changes, trying to move every bit from language to library that is >> possible - without compromising the result too much, of course (e.g. due >> to template bloat like in the older D->ObjC bridge). Maybe it's possible >> to put some things into __traits or other more general facilities to >> avoid changing the language grammar. > > I don't see what could be but in __traits that could help. Do you have > any suggestions? 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; } } 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). 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. Not sure about constructors in interfaces, they seem a bit odd, but using "init" instead and letting "new" call that is also odd... You already mentioned @IBAction and @IBOutlet, those can obviously be UDAs, as well as @optional and other similar keywords. Maybe it's possible like this to reduce the syntax additions to extern(Objective-C) and possibly constructors in interfaces. > >> On the other hand I actually very much hate to suggest this, as it >> probably causes a lot of additional work. But really, we shouldn't take >> *any* language additions lightly, even relatively isolated ones. Like >> always, new syntax must be able to "pull its own weight" (IMO, of >> course). > > I would say that for anyone remotely interested in Mac OS X or iOS > development it pull its own weight several times over. In my opinion I > think it's so obvious it pulls its own weight I shouldn't need to > justify the changes. > 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.