On 2010-09-18 02:18, Michel Fortin wrote:
On 2010-09-17 14:48:54 -0400, Jacob Carlborg <[email protected]> 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
