Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change C# names of P/Invokes of objc_msgSend to be call-site specific. #47608

Merged
6 commits merged into from
Feb 2, 2021

Conversation

jkoritzinsky
Copy link
Member

As requested in #47592 (comment), I've renamed all instances of objc_msgSend P/Invokes to have call-site specific names since objc_msgSend has callsite-specific signatures.

@ghost
Copy link

ghost commented Jan 29, 2021

Tagging subscribers to this area: @safern, @tannergooding
See info in area-owners.md if you want to be subscribed.

Issue Details

As requested in #47592 (comment), I've renamed all instances of objc_msgSend P/Invokes to have call-site specific names since objc_msgSend has callsite-specific signatures.

Author: jkoritzinsky
Assignees: -
Labels:

area-System.Drawing

Milestone: -

[DllImport("libobjc.dylib", EntryPoint = "objc_msgSend_stret")]
public static extern void get_bounds(ref Rect arect, IntPtr basePtr, IntPtr selector);
[DllImport("libobjc.dylib", EntryPoint = "objc_msgSend")]
public static extern bool get_isFlipped(IntPtr handle, IntPtr selector);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is size of bool in Objective-C - does it match what the marshaler is going to use here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not. This is a bug. I'll fix it tomorrow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

@jkoritzinsky jkoritzinsky Jan 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and it will cause failures on MacOS arm64.

@jkotas
Copy link
Member

jkotas commented Jan 29, 2021

Also change src\libraries\common\src\Interop\OSX\Interop.libobjc.cs for consistency?

@jkoritzinsky
Copy link
Member Author

Also change src\libraries\common\src\Interop\OSX\Interop.libobjc.cs for consistency?

Already done 👍🏻

@jkotas
Copy link
Member

jkotas commented Jan 29, 2021

Ah, I have missed that it is part of this PR. get_operatingSystemVersion in that file is still on the old plan.

@jkoritzinsky
Copy link
Member Author

We can’t really rename that one very well with the given model since we already have to customize the entry-point based on platform.

[DllImport("libobjc.dylib", EntryPoint = "objc_msgSend")]
public static extern IntPtr intptr_objc_msgSend(IntPtr basePtr, IntPtr selector);
[DllImport("libobjc.dylib", EntryPoint = "objc_msgSend_stret")]
public static extern void void_objc_msgSend_stret_rrect(ref Rect arect, IntPtr basePtr, IntPtr selector);
Copy link
Member

@jkotas jkotas Jan 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this look better as rect_objc_msgSend_stret(out Rect arect ? The Xamarin examples are not 100% consistent - majority of them are using out, a few exception are using ref for some reason.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it particularly matters. We could also have the Rect type as the return value if we want.

@jkotas
Copy link
Member

jkotas commented Jan 29, 2021

We can’t really rename that one very well with the given model since we already have to customize the entry-point based on platform.

Should the per-platform customization include change in the return value as well (void vs. NSOperatingSystemVersion)? Otherwise, if we are ok with using the return type assuming that the calling conventions will match, we can do it everywhere for consistency and to make the code a bit more readable.

Is there an established pattern that the Xamarin bindings use to deal with this difference between platforms?

@jkoritzinsky
Copy link
Member Author

We can do return everywhere and it will work.

The Xamarin bindings (at least the ones on my VS4Mac instance) use out parameters for objc_msgSend_stret.

Which would you prefer that we do?

@jkotas
Copy link
Member

jkotas commented Jan 30, 2021

I think we can

  • either stick to Xamarin conventions completely (e.g. use out to return)
  • grow our own modification of Xamarin conventions to make the code more pleasant to read (e.g. use regular return instead of out). If we grow our own modification to make the code more pleasant to read, we can do more than that. For example, we can also omit the argument names from the method name since they are not necessary to disambiguate.

Either one of these is fine with me.

@jkoritzinsky
Copy link
Member Author

I decided to follow the Xamarin convention.

@ghost
Copy link

ghost commented Feb 2, 2021

Hello @jkoritzinsky!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 1562cf7 into dotnet:master Feb 2, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Mar 4, 2021
@jkoritzinsky jkoritzinsky deleted the rename-msgsend branch September 28, 2021 00:04
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants