On 2014-12-17 20:51, Christian Schneider wrote:

> OMG, what did you do? all my beautiful appkit and foundation header
> files are destroyed! do you plan any other such attacks?

Hopefully no :)

> lol, i must admit, i was a bit shocked about this sudden surprise. what
> is the main motivation? i thought the old style looked good because it
> made visually clear that it was glue into objective-c, as it looked very
> familiar.

The reason for the change is that the old syntax, [foo:bar:], required language changes wheres the new syntax, @selector("foo:bar:"), doesn't. When D/Objective-C was initially created D didn't support UDA's, that's why a new syntax was invented. If D had supported UDA's back then, that would most likely have been used.

Hopefully this will also increase the chances of D/Objective-C being merged with upstream DMD.

> with a little scripting / string processing i can adapt to the
> new style, i guess.

I updated all the tests quickly with some global search and replace using regular expression.

-- 
/Jacob Carlborg

> The reason for the change is that the old syntax, [foo:bar:], required language changes wheres the new syntax, @selector("foo:bar:"), doesn't. When D/Objective-C was initially created D didn't support UDA's, that's why a new syntax was invented. If D had supported UDA's back then, that would most likely have been used.
>
> Hopefully this will also increase the chances of D/Objective-C being merged with upstream DMD.

OK! Yes I understand, the merge with upstream DMD is one of the most important things, i totally agree.

> I updated all the tests quickly with some global search and replace using regular expression.

Regex is one of my weaknesses. If you don't mind sharing yours (and if you have them still lying around) please send to schneider at gerzonic.net, this would be greatly appreciated, and would make my life a bit easier.

this is all a great and exciting adventure ;)

On 2014-12-18 23:31, Christian Schneider wrote:

> Regex is one of my weaknesses. If you don't mind sharing yours (and if
> you have them still lying around) please send to schneider at
> gerzonic.net, this would be greatly appreciated, and would make my life
> a bit easier.

These are two simple regular expression that you can use:

\)\s*\[([\w:]+)\];$

Replace with

) @selector("$1");

And

\)\s*\[([\w:]+)\]$

Replace with

) @selector("$1")

They make some assumption about the code. They will match:

a closing parenthesis ->
zero or more spaces ->
opening bracket ->
at least one or more of: A-Z, a-z, a colon or 0-9 ->
closing bracket ->
semicolon ->
end of line

In the above description the arrow, "->", should be read as "followed by".

When replacing the text, $1 will represent what's caught in the first group. In this case what's in between the brackets.

The difference between the first and the second regular expression is the trailing semicolon, to handle both extern declarations and methods defined in the D source code.

These regular expression assume you only have the selector on the right side of the method declaration, i.e. no UDA's or similar.

-- 
/Jacob Carlborg

awesome, thank you very much!

Just for my information: Why is it no longer possible to have multiple d methods (or overloaded constructors) to map to the same Objective-C implementation?

I though it was quite nice to have overloaded d constructors for the various init.. methods.

Was just upgrading everything to the latest Github, dmd, druntime (the d-objc branch). It does not seem to be able to link into the AppKit and Foundation anymore. dmd fails silently with error code -11

I uploaded a very stripped down project (containing everything) that you might want to have a look at, it just declares a NSString and tries to log it:

http://diveframework.com/files/supersimple.zip

dub -v gives really no clue whatsoever is failing. I am really sorry that I can not be more specific / helpful for making this work.

On 2014-12-25 14:12, Christian Schneider wrote:
> Just for my information: Why is it no longer possible to have multiple d
> methods (or overloaded constructors) to map to the same Objective-C
> implementation?
>
> I though it was quite nice to have overloaded d constructors for the
> various init.. methods.

Can you give me an example of what's not working?

-- 
/Jacob Carlborg

On 2014-12-25 15:30, Christian Schneider wrote:
> Was just upgrading everything to the latest Github, dmd, druntime (the
> d-objc branch). It does not seem to be able to link into the AppKit and
> Foundation anymore. dmd fails silently with error code -11
>
> I uploaded a very stripped down project (containing everything) that you
> might want to have a look at, it just declares a NSString and tries to
> log it:
>
> http://diveframework.com/files/supersimple.zip
>
> dub -v gives really no clue whatsoever is failing. I am really sorry
> that I can not be more specific / helpful for making this work.

It's the destructor in NSObject that causes the problem. I'll take a look. Remove that and your example will work, after you import the missing "foundation.runtime" in "app".

-- 
/Jacob Carlborg

On Friday, 26 December 2014 at 17:47:29 UTC, Jacob Carlborg wrote:
> On 2014-12-25 14:12, Christian Schneider wrote:
>> Just for my information: Why is it no longer possible to have multiple d
>> methods (or overloaded constructors) to map to the same Objective-C
>> implementation?
>>
>> I though it was quite nice to have overloaded d constructors for the
>> various init.. methods.
>
> Can you give me an example of what's not working?


previously it was possible to have a few D methods "point" to the same Objective-C method like this:

    NSView initWithFrame(NSRect frameRect) @selector("initWithFrame:")  ;
    this(NSRect frameRect) @selector("initWithFrame:")  ;

Now with the latest version I get this error for the above two lines:

../../Interfaces/appkit/view.d(19): Error: constructor appkit.view.NSView.this Objcective-C selector 'initWithFrame:' already in use by function 'initWithFrame'.

I thought, it was a nice convenience to make both potential types of programmers happy, those leaning more towards Objective-C / named parameters can use the verbose, first option, while the ones coming more from C/C++ can use the shortcut, the 2nd option.

But it's no big deal, I'll just remove the "shortcut".  My question was more for understanding why it was a) possible in the past and b) what is the motivation behind the decision that it is no longer possible now.

On 2014-12-29 20:01, Christian Schneider wrote:

> previously it was possible to have a few D methods "point" to the same
> Objective-C method like this:
>
>      NSView initWithFrame(NSRect frameRect) @selector("initWithFrame:")  ;
>      this(NSRect frameRect) @selector("initWithFrame:")  ;
>
> Now with the latest version I get this error for the above two lines:
>
> ../../Interfaces/appkit/view.d(19): Error: constructor
> appkit.view.NSView.this Objcective-C selector 'initWithFrame:' already
> in use by function 'initWithFrame'.
>
> I thought, it was a nice convenience to make both potential types of
> programmers happy, those leaning more towards Objective-C / named
> parameters can use the verbose, first option, while the ones coming more
> from C/C++ can use the shortcut, the 2nd option.
>
> But it's no big deal, I'll just remove the "shortcut".  My question was
> more for understanding why it was a) possible in the past and b) what is
> the motivation behind the decision that it is no longer possible now.

I'm not sure what's happened. Perhaps it's a bug that now have been fixed. I'll add it to my todo list.

-- 
/Jacob Carlborg