On 2021-01-24 04:50, mori wrote:
I feel as if I came across rather... pessimistic. I do want to help.
Awesome :)
Yesterday I spent some time trying to port the (cocoa) Program class to D using `extern (Objective-C)`. What I've got works, but the main difference (as you'd probably know) is that Java the Objective-C lib itself (i.e. <objc/*.h>) which allows them to create instances with `new`. This (seemingly) isn't possible with `extern (Objective-C)` classes.
Yes, that's correct. The way Eclipse has created the Objective-C bindings is to wrap all Objective-C classes in Java classes. That means that for each Objective-C object there will also be a Java object. This is to create friendlier API. But in D, since there's direct language support for using Objective-C classes, that's not necessary. There will only be an Objective-C object.
Instead of Java code looking like this: NSAlert alert = (NSAlert) new NSAlert().alloc().init(); The D code will look just like this: NSAlert alert = NSAlert.alloc().init();
I'll use that code as a base, but did you want to stick to using the `objc_msgSend` style code or `extern (Objective-C)`?
It's better to use the `extern (Objective-C)` style. This will result in the code looking slightly less like the Java code, but it will be more correct.
Also (this applies to Gtk as well), did you want me to send pull requests against the main DWT repository, or the individual repositories?
I guess you have already figured this out, but the org.eclipse.swt.win32.win32.x86, org.eclipse.swt.snippets and org.eclipse.swt.gtk.linux.x86 repositories have been merged into the dwt repository.
As for the Cocoa port. It depends on what approach you want to take. Finish the existing port in D1 or start fresh and incrementally porting 4.7.3. For the one doing the code reviews, it's much easier if the diffs are smaller.
Haven't run into this issue myself yet, but will keep it mind.
As soon as some methods return NSRect you'll run into this. A workaround is to manually call the Objective-C runtime function `objc_msgSend_stret`.
Also, keep in mind that `float` and `double` are initialized to 0.0 by default in Java, while in D they're initialized to NaN.
I mentioned why I chose 4.7.3 in the pull request, but there is also the benefit that doesn't depend on `gnomeui` and `gnomevfs` which aren't available in some package repositories now. (Mainly Debian based it seems.)
Since you're the one doing the work and if 4.7.3 is fine with you, then that's great.
I don't imagine there are any broken APIs in the win32 version (Microsoft is good with backwards compatibility after all), just not sure on the Cocoa side.
Apple has a tendency to, not necessarily break APIs but change things that might cause problems. Especially if applications are not implemented the way that Apple thinks they should be implemented. Like dark mode. They do deprecate APIs as well.
-- /Jacob Carlborg
