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

[Jacob Carlborg]

On 2010-09-18 02:18, Michel Fortin wrote:
> On 2010-09-17 14:48:54 -0400, Jacob Carlborg <doob at me.com> said:
>
>> On 2010-09-17 19:45, Michel Fortin wrote:
>>> 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?
>
> No. This would be changing D's semantics. D, like C, does not require
> names for parameters in function prototypes, nor does it require names
> to be the same in overridden functions. And it's the same for
> Objective-C: parameters names are distinct from the selector and can be
> changed at will without changing the method's name.
>
> This Objective-C method:
>
> - (id)getObject:(id)anObject forKey:(id)aKey;
>
> becomes
>
> NSObject getObject(NSObject anObject, NSObject aKey) [getObject:forKey:];
>
> In both cases, anObject and aKey can be changed without breaking
> compatibility. They're basically just names for local variables inside
> the function.

Ok, now I'm not sure I understand. If you don't specify a selector for a 
declared method, how will the selector look like? In your example above, 
if you don't specify the selector how will it be something like:

getObject:: ?

>>> 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.
>
> You misunderstood. I have no intention of changing the ABI for D
> delegates or anything already existing in D.
>
> But it shouldn't be too hard to wrap delegates in blocks. You probably
> don't even need help from the compiler to do this (unless you want it to
> be implicit). Take a look at the spec for blocks:
> <http://clang.llvm.org/docs/Block-ABI-Apple.txt>

Ok.

>>> 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.
>
> I know the importance of categories. I believe there should be a way to
> declare categories from existing Objective-C frameworks and use them.
> What I'm unsure of is if you should be allowed to *define* your own, but
> I admit being able to declare them but not define them would be strange.

Ok.

>>> 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.
>
> An idea would be to substitute the GC in druntime with AutoZone and have
> it manage every piece of memory, but Apple's garbage collector doesn't
> support pointers to interior of blocks so it's impossible to use for
> regular D even if we were to add the memory barriers it wants. And
> having two collectors running at the same time sounds like trouble.

Ok.

>> Please let me know when you start to think more about all this.
>
> I suggest you subscribe to my d-objc mailing list. I'll be posting about
> my progress there.
> <http://lists.michelf.com/mailman/listinfo/d-objc>

Done.


-- 
/Jacob Carlborg