Re: DIP87: Enhanced Foreign-Language Binding
On 2016-01-23 02:31, Anon wrote:
Ideally, by whether the `extern()` forms a block or it is attached
directly to the symbol. I understand that wouldn't work with existing
implementation in the compiler, but hopefully it wouldn't be too
difficult to do. But I know nothing of compiler internals so am probably
wrong.
That will change the behavior compared to how all other attributes work.
There's no difference for these syntaxes:
extern(C) int a;
extern(C) { int a; }
extern(C): int a;
Or:
public int a;
public { int a; }
public: int a;
I'll have to look into this more. My cursory reading told me of
"instance" methods and "class" methods, that get mangled as
"_i__..." and "_c__..."
respectively. Is this what you are talking about?
No. In Objective-C there's a protocol (interface) called "NSObject" and
a class called "NSObject". It needs to be possible to do this:
extern(Objective-C)
class NSObject {} // standard mangling, NSObject
extern(Objective-C) pragma(mangle, "NSObject")
interface NSObjectProtocol {} // custom mangling, NSObject
The mangling for a method is more like L_OBJC_SELECTOR_REFERENCES_0.
Where 0 is an increasing number.
If you have access to a Mac you can try compiling this [1] example and
list all symbols with the "nm" command.
Sure, but when using ObjC code from D:
extern(Objective-C) class Something {
void moveTo(float x, float y) @selector("x:y:");
}
// Elsewhere
something.moveTo(1,2);
I don't see how the selector is doing anything more than mangling here.
Even if you have multiple methods in D that mangle to the method name in
ObjC (minus parameters), that selection is done by D, which then mangles
the name according to the selector, right? If not, do you have an
example handy to illustrate?
No. The above call to "moveTo" is lowered to something like this:
objc_msgSend(something, "x:y:", 1, 2);
The Objective-C runtime will find the correct method implementation to
call based on the selector.
[1] http://dlang.org/spec/objc_interface.html#usage-example
--
/Jacob Carlborg
Re: DIP87: Enhanced Foreign-Language Binding
On Friday, 22 January 2016 at 16:37:31 UTC, Jacob Carlborg wrote:
On 2016-01-21 05:21, Anon wrote:
Seeing the recent extern(C++) threads, and much concern
therein, I'd
like to propose DIP87: http://wiki.dlang.org/DIP87
Destroy to your heart's content.
* How do you plan to differentiate specifying the namespace
compared with specifying the mangled name for an extern(C++)
symbol?
Ideally, by whether the `extern()` forms a block or it is
attached directly to the symbol. I understand that wouldn't work
with existing implementation in the compiler, but hopefully it
wouldn't be too difficult to do. But I know nothing of compiler
internals so am probably wrong.
* For Objective-C bindings one needs to be able to specify the
mangled name for a class or interface without affecting the
names of the methods. It's required because in Objective-C it's
possible to have the same name for a class and a protocol
(interface). In the Foundation framework (standard library)
there are a class "Object" and a protocol "Object"
I'll have to look into this more. My cursory reading told me of
"instance" methods and "class" methods, that get mangled as
"_i__..." and "_c__..."
respectively. Is this what you are talking about?
* When creating Objective-C bindings it's basically required to
specify the selector for every method
I know, because of the parameter names being part of the API (and
mangled name). I still think the approach described in the DIP
should be workable.
* In Objective-C the mangled name and the selector is not the
same. The mangled name is for the linker to find the correct
symbol. The selector is for finding the correct method
implementation at runtime
Sure, but when using ObjC code from D:
extern(Objective-C) class Something {
void moveTo(float x, float y) @selector("x:y:");
}
// Elsewhere
something.moveTo(1,2);
I don't see how the selector is doing anything more than mangling
here. Even if you have multiple methods in D that mangle to the
method name in ObjC (minus parameters), that selection is done by
D, which then mangles the name according to the selector, right?
If not, do you have an example handy to illustrate?
Re: DIP87: Enhanced Foreign-Language Binding
On 2016-01-21 05:21, Anon wrote: Seeing the recent extern(C++) threads, and much concern therein, I'd like to propose DIP87: http://wiki.dlang.org/DIP87 Destroy to your heart's content. * How do you plan to differentiate specifying the namespace compared with specifying the mangled name for an extern(C++) symbol? * For Objective-C bindings one needs to be able to specify the mangled name for a class or interface without affecting the names of the methods. It's required because in Objective-C it's possible to have the same name for a class and a protocol (interface). In the Foundation framework (standard library) there are a class "Object" and a protocol "Object" * When creating Objective-C bindings it's basically required to specify the selector for every method * In Objective-C the mangled name and the selector is not the same. The mangled name is for the linker to find the correct symbol. The selector is for finding the correct method implementation at runtime -- /Jacob Carlborg
Re: DIP87: Enhanced Foreign-Language Binding
On Thursday, 21 January 2016 at 04:21:06 UTC, Anon wrote: Seeing the recent extern(C++) threads, and much concern therein, I'd like to propose DIP87: http://wiki.dlang.org/DIP87 Destroy to your heart's content. This propose to change everything while not even providing anything more than what we already have. If it was to start from scratch, why not, but clearly, in its current shape, this doesn't pay for itself.
Re: DIP87: Enhanced Foreign-Language Binding
On 21/01/16 6:46 PM, Anon wrote: snip I thought I did a good enough job of explaining that in the DIP so I wouldn't have to here. I was trying to explain some better semantics because how it is currently with strings can be and is a bit ambiguous.
Re: DIP87: Enhanced Foreign-Language Binding
On Thursday, 21 January 2016 at 04:42:00 UTC, Rikki Cattermole wrote: On 21/01/16 5:21 PM, Anon wrote: Seeing the recent extern(C++) threads, and much concern therein, I'd like to propose DIP87: http://wiki.dlang.org/DIP87 Destroy to your heart's content. It was great until I saw: extern(auto, "myMoveTo:") After all: extern(C/C++/D/Objective-C[, string]) Is that string meant for raw mangling or effect mangling in the form of selector? Just no, leave @selector alone I think. I don't know ObjC, so I had to wing it on the details there. The strings in extern(, "str") would get sent through Foo's mangler. For ObjC, I currently imagine those strings forming the selector, much the same way it is specified through @selector. That ObjC's mangling mostly consists of 's/:/_/g' is irrelevant. I want *all* language binding to happen with a uniform interface. No more one-off hacks for a particular language (which is exactly what extern(C++,ns) and @selector are). You have the same problem with c++ namespaces. I don't see a problem. You'll have to be more specific. Perhaps this is slightly wrong. extern(string) Is the only way to force a specific mangling. There is no extern(string) in this proposal, nor is there a way to force a specific mangling, which (AFAIK) was only introduced to allow linking to C symbols that happened to be keywords. Where as extern(C/C++/D/Objective-C[, string]) with the string altering in C++ and Objective-C mode. It mangles regardless. Any and all of the extern() modes mangle. That C's mangling is to just return the input string is irrelevant. So the only difference is extern(string) vs pragma(mangle, string) Little harder sell, but I think might be worth it for cleaning up the language. The difference is that it can mangle symbols correctly, even if the symbol is a D keyword. Currently: extern(C++) pragma(mangle, "delegate") int delegate_(); ...yields a mangled name of "delegate", and there is no way to get the compiler to mangle the symbol correctly. Meaning you have to (ab)use pragma(mangle) and provide it with the full mangled name yourself. And `version()` it appropriately to deal with gcc/clang vs MSVC/DMC mangling. With this DIP: extern(C++, "delegate") int delegate_(); ... would yield a mangled name of "_Z8delegatev" (or similar). I thought I did a good enough job of explaining that in the DIP so I wouldn't have to here.
Re: DIP87: Enhanced Foreign-Language Binding
On 21/01/16 5:21 PM, Anon wrote: Seeing the recent extern(C++) threads, and much concern therein, I'd like to propose DIP87: http://wiki.dlang.org/DIP87 Destroy to your heart's content. It was great until I saw: extern(auto, "myMoveTo:") After all: extern(C/C++/D/Objective-C[, string]) Is that string meant for raw mangling or effect mangling in the form of selector? Just no, leave @selector alone I think. You have the same problem with c++ namespaces. Perhaps this is slightly wrong. extern(string) Is the only way to force a specific mangling. Where as extern(C/C++/D/Objective-C[, string]) with the string altering in C++ and Objective-C mode. So the only difference is extern(string) vs pragma(mangle, string) Little harder sell, but I think might be worth it for cleaning up the language.
DIP87: Enhanced Foreign-Language Binding
Seeing the recent extern(C++) threads, and much concern therein, I'd like to propose DIP87: http://wiki.dlang.org/DIP87 Destroy to your heart's content.
