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

Newtypes instead of monolithic id #173

Open
bors-servo opened this issue Feb 1, 2018 · 11 comments
Open

Newtypes instead of monolithic id #173

bors-servo opened this issue Feb 1, 2018 · 11 comments

Comments

@bors-servo
Copy link
Contributor

Issue by fkaa
Sunday Feb 28, 2016 at 16:40 GMT
Originally opened as servo/cocoa-rs#117


Is there any reasoning for using traits and implementing them onto id rather than creating newtypes such as struct NSString(id)? I've been running into name collisions with the former a lot lately.

@bors-servo
Copy link
Contributor Author

Comment by jdm
Sunday Feb 28, 2016 at 18:19 GMT


I would be in favour of making this change; @pcwalton can you think of any reason not to?

@bors-servo
Copy link
Contributor Author

Comment by jdm
Sunday May 15, 2016 at 14:55 GMT


@metajack Any objection here?

@bors-servo
Copy link
Contributor Author

Comment by metajack
Sunday May 15, 2016 at 16:30 GMT


This is a question best answered by @pcwalton. It might help in decision making to see a concrete example of how this changes things before and after.

@bors-servo
Copy link
Contributor Author

Comment by fkaa
Sunday May 15, 2016 at 17:54 GMT


I've had some success with this inside my own bindings, and I can definitely see the use for this here.

jrmuizel pushed a commit to jrmuizel/core-foundation-rs that referenced this issue Feb 2, 2018
Update bitflags to 1.0 and bump version

<!-- Reviewable:start -->
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/cocoa-rs/173)
<!-- Reviewable:end -->
@pcwalton
Copy link
Contributor

I'll start working on this.

@savannidgerinel
Copy link

This is also of interest to me, and I would like to know how I can help.

@jdm
Copy link
Member

jdm commented Aug 19, 2019

I think the best way to help would be to convert a couple representative modules to use newtypes and make a pull request so we can evaluate the tradeoffs of doing the full conversion. Nobody else is actively looking into it right now.

@savannidgerinel
Copy link

Seems simple enough. I could start by converting everything involved with the Hello World app. My attempts are going to be pretty naive to begin with.

I have no experience with Cocoa programming outside of a few tools and an attempt that I made over the weekend of creating a type-safe wrapper around this library.

For memory management purposes, I was turning off the autorelease pool. I'm assuming I need to make the objects part of the Rust borrow system and avoid having the OS deallocate the object IDs that the Rust types are pointing to. Is this reasonable?

@jdm
Copy link
Member

jdm commented Aug 19, 2019

I honestly don't have enough Cocoa experience to answer that question, unfortunately. Maybe @jrmuizel does?

@savannidgerinel
Copy link

Then I'll just dig in over the next few days, do my best, and let y'all tell me if I've gone wrong.

@savannidgerinel
Copy link

I've prototyped this. The process looks long and tedious the way I'm doing it, but I'm also doing it more in the sense of a Rust API instead of mimicking the Objective C API directly. I've created a submodule named cocoa-safe in which I am building in parallel to the cocoa module and in which I have hello_world working, except for the NSRunningApplication object.

https://github.com/savannidgerinel/core-foundation-rs/tree/cocoa-safe

I welcome comments. However, this is probably too big to manage as just a single issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants