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

[Michel Fortin]

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.


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


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


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


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


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