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

Default method names #35

Open
anderslanglands opened this issue Feb 20, 2021 · 6 comments
Open

Default method names #35

anderslanglands opened this issue Feb 20, 2021 · 6 comments
Assignees
Labels
enhancement New feature or request
Projects

Comments

@anderslanglands
Copy link
Contributor

Reopening this discussion. We should provide default name transformations for cons/destructors, operators and polymorpic functions so that the generated code will at least compile, even if the names are ugly, and then someone writing a binding can go back and fix it afterwards.

Overloads

This is easy, just enumerate the overloads as they're found:

void fun(float);
void fun(int);
void fun(short);

// becomes...
void fun(float);
void fun2(int);
void fun3(short);

Constructors & destructors

I think new and delete are probably the most sensible, or construct and destruct. In the previous discussion, new and delete felt overloaded because I was anticipating using opaqueptr for everything and mallocing in the API layer, but I feel like we're now leaning towards opaquebytes for most things and leave opaqueptr for things that can't be constructed by the user, in which case the library will be providing the creation methods manually so there's less worry about confusion.

struct Foo {
    Foo(float);
    Foo(int);
    Foo(short);
    Foo(const Foo& rhs);
};

// becomes...
void Foo_new(Foo* self, float);
void Foo_new2(Foo* self, int);
void Foo_new3(Foo* self, short);
void Foo_copy(Foo* self, Foo const* rhs);

Operators

We should just take the function names from the equivalent Rust traits here since they're logical, concise and consistent.

struct Foo {
    Foo operator+(const Foo& rhs) const;
    Foo& operator=(const Foo& rhs);
    Foo& operator+=(const Foo& rhs);
};

// becomes...
void Foo_add(Foo const* self, Foo const* rhs, Foo* result);
void Foo_assign(Foo* self, Foo const* rhs);
void Foo_add_assign(Foo* self, Foo const* rhs);
@luke-titley
Copy link
Collaborator

This seems fine to me. For me new and delete tend to imply allocation but I think that's fine. We can say, new is where allocation may or may not happen (depending on opaqueptr), and same with delete.

@anderslanglands
Copy link
Contributor Author

Hmm well I guess allocation will never happen if we always use opaquebytes for anything that has a public constructor. I'm liking this less now that I think about it. what about ctor and dtor?

@anderslanglands
Copy link
Contributor Author

OK so how about

Foo() // -> Foo_ctor
Foo(const Foo&) // -> Foo_ctor_copy
~Foo() //-> Foo_dtor

Foo& operator=(const Foo&) // -> Foo_assign

Foo& operator++() // -> Foo_op_inc
Foor& operator--() // -> Foo_op_dec

@anderslanglands
Copy link
Contributor Author

And of course

Foo& operator[](int i) // -> Foo_index
const Foo& operator[](int i) const // -> Foo_index_const

@luke-titley
Copy link
Collaborator

Foo() // -> Foo_ctor
Foo(const Foo&) // -> Foo_ctor_copy
~Foo() //-> Foo_dtor

Foo& operator=(const Foo&) // -> Foo_assign

Foo& operator++() // -> Foo_op_inc
Foor& operator--() // -> Foo_op_dec

Foo& operator[](int i) // -> Foo_index
const Foo& operator[](int i) const // -> Foo_index_const

Fine by me.

@scott-wilson scott-wilson added this to To do in Cppmm Apr 24, 2021
@luke-titley luke-titley moved this from To do to Review in progress in Cppmm May 4, 2021
@luke-titley
Copy link
Collaborator

I think this is done now too.

@luke-titley luke-titley moved this from Review in progress to Done in Cppmm May 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Cppmm
Done
Development

No branches or pull requests

2 participants