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

On 2010-09-18 06:10:53 -0400, Jacob Carlborg <doob@me.com> said:

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

Exactly. Note that this is a valid selector name.

Though I might decide on something else later. I'm thinking about mangling the argument types in the selector to make it work better with overloading.

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

On 2010-09-18 16:36, Michel Fortin wrote:
> On 2010-09-18 06:10:53 -0400, Jacob Carlborg <doob@me.com> said:
>
>> 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:: ?
>
> Exactly. Note that this is a valid selector name.
>
> Though I might decide on something else later. I'm thinking about
> mangling the argument types in the selector to make it work better with
> overloading.

Yes, I know it's a valid selector name, I've seen it in a few places. But as I see it, in most cases where there is more than one parameter you will have to declare the selector explicitly.

-- 
/Jacob Carlborg

On 2010-09-18 16:36, Michel Fortin wrote:
> On 2010-09-18 06:10:53 -0400, Jacob Carlborg <doob@me.com> said:
>
>> 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:: ?
>
> Exactly. Note that this is a valid selector name.
>
> Though I might decide on something else later. I'm thinking about
> mangling the argument types in the selector to make it work better with
> overloading.

What about two methods that take the same number of parameters and of the same types but have two distinct selectors in Objective-C, like insertSublayer:below: and insertSublayer:above: in the CALayer class in the QuartzCore framework. Should those be translated to insertSublayerBelow or insertSublayer_below_ or something like that? Or have you planed a syntax that will solve this some other way?

-- 
/Jacob Carlborg

On 2010-09-20 04:23:38 -0400, Jacob Carlborg <doob@me.com> said:

> On 2010-09-18 16:36, Michel Fortin wrote:
>> Though I might decide on something else later. I'm thinking about
>> mangling the argument types in the selector to make it work better with
>> overloading.
> 
> What about two methods that take the same number of parameters and of the same types but have two distinct selectors in Objective-C, like insertSublayer:below: and insertSublayer:above: in the CALayer class in the QuartzCore framework. Should those be translated to insertSublayerBelow or insertSublayer_below_ or something like that? Or have you planed a syntax that will solve this some other way?

There is no automatic conversion from a selector to a D method name: you specify the method name (as usual) and you specify the selector (if you care about the selector, like in bindings). If you have a script that automatically creates bindings, then that script is the one that must figure out what method name to use for what selector.

Because of this, there is no need for the D method name to be related to the selector. When you call a method, the method name is used to find the method declaration; and the declaration contains the selector to use. Calling undeclared methods is unsupported (unlike in Objective-C).

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

On 2010-09-20 16:19, Michel Fortin wrote:
>> What about two methods that take the same number of parameters and of
>> the same types but have two distinct selectors in Objective-C, like
>> insertSublayer:below: and insertSublayer:above: in the CALayer class
>> in the QuartzCore framework. Should those be translated to
>> insertSublayerBelow or insertSublayer_below_ or something like that?
>> Or have you planed a syntax that will solve this some other way?
>
> There is no automatic conversion from a selector to a D method name: you
> specify the method name (as usual) and you specify the selector (if you
> care about the selector, like in bindings). If you have a script that
> automatically creates bindings, then that script is the one that must
> figure out what method name to use for what selector.
>
> Because of this, there is no need for the D method name to be related to
> the selector. When you call a method, the method name is used to find
> the method declaration; and the declaration contains the selector to
> use. Calling undeclared methods is unsupported (unlike in Objective-C).

Makes sense.

-- 
/Jacob Carlborg