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

[Jacob Carlborg]

On 2010-09-17 19:45, Michel Fortin wrote:
> 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).

Will it use the parameter names to build the selector as well?

> 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).

Ok, that make sense.

> 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:");

I also made a selector method that takes an alias as a parameter and 
automcatcally builds a selector based on the name of the method and the 
parameter names.

>> 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.

Exactly, but I assume that would make them incompatible with existing D 
delegates.

> 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.

Well, most of the stuff that makes Objective-C what it is, is not very 
D-like. D and Objective-C has different object models, D is Simula based 
and Objective-C is based on Smalltalk. But categories are a must, I mean 
a large part of the standard classes (i.e. NSObject) is split in 
categories. With the standard frameworks that wouldn't be such a big 
problem, just make regular methods of it in the class it extends, but 
when a non-standard framework have categories extending standard classes 
we start to have a problem.

> 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.

What about using AutoZone, the Objective-C garbage collector? But that 
would require memory barriers I assume.

Please let me know when you start to think more about all this.

-- 
/Jacob Carlborg