D/Objective-C: hit a dead end, start anew

[Michel Fortin]

On 2010-09-17 11:50:51 -0400, Jacob Carlborg <doob at me.com> said:

> Sounds good, I also once thought about adding extern (Objective-C) to 
> the language. About the selector syntax, wouldn't it be better to have 
> the same syntax as in Objective-C, 
> @selector(performSelector:withObject:). I mean D already has the 
> @annotation syntax for annotations/attributes I don't think we need yet 
> another one. I would also be nice to use 
> @selector(performSelector:withObject:) as an expression (or what is 
> called) to get the selector to a method just like in Objective-C.

I though about it, but decided against it. The @attribute syntax in D 
isn't meant *at this time* to accept arguments. Nor is the DMD front 
end ready to accept arguments for attributes. I don't want to inject my 
code in the parsing of attributes and their propagation through the 
frontend. Perhaps one day attributes will accept arguments and we could 
reconsider. But in the meanwhile I try to avoid touching things which 
are good candidates for possible future extensions to the regular D 
language.

Also note that member functions of an extern (Objective-C) class or 
interface always have implicitly a selector (made from the function's 
name followed by as many colons as there are arguments). The special 
selector syntax is only needed to specify a different selector than the 
original. I'm not sure if this kind of implicit thing that you can 
override fit very well with the notion of an attribute (certainly not 
the current notion which is basically a binary flag).

For the same reason, I don't think reusing Objective-C's 
"@selector(setObject:forKey:)" syntax for selector literals is a very 
good idea. I'm not exactly sure what selector literals should look 
like, but I'm currently leaning about simply making it a function 
intrinsic:

	import objc;

	SEL s = objc.selector("setObject:forKey:");


> Have you thought anything about the blocks that Apple added in Snow 
> Leopard, if those could be supported as well?
> 
> What about Objective-C categories?

Ideally blocks would be the same as delegates, but I hadn't given them 
much thought yet.

I'm not sure whether I want to support creating new categories in D; 
categories are quite "un-D-like" and despite their usefulness they're 
clash-prone. But I sure want to be able to access categories from 
existing Objective-C frameworks. So how exactly this would work? I 
don't know.

In any case, I have much work to do before it's time to think about 
categories and blocks. The most basic problem to solve in this all new 
Objective-C "bridge" is the memory management. But I don't want to look 
at this too much until I get the basics working.


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