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

Naming conventions for "private" struct members. #73

Open
lerno opened this issue Nov 25, 2018 · 2 comments
Open

Naming conventions for "private" struct members. #73

lerno opened this issue Nov 25, 2018 · 2 comments

Comments

@lerno
Copy link
Collaborator

lerno commented Nov 25, 2018

I was looking at this: https://github.com/c2hub/c2vector/blob/master/c2vector/c2vector.c2

And realized that maybe C2 needs a convention (or a way) to name / signal "internal" (I wouldn't use 'private') fields.

There are a few options:

  1. Name convention: "_foo" – Dart does this, and they actually skip "private/public" by saying anything with "_" is private.
  2. Keyword: "private foo" / "internal foo" / "local foo" in the struct declaration together with have to use some special way to get hold of it. In the case of c2vector2: c = v.capacity and maybe a = v.$total or c = (private v).total or c = private v.total (not beautiful solutions, just describing the options we have)
  3. Sigil: e.g. "$foo" like in type Foo struct { int $foo; }
@bvdberg
Copy link
Member

bvdberg commented Nov 27, 2018

This is related to the discussions on whether to allow struct functions to use (struct) variables without the self. prefix. Just like C++ etc. I think this will make a lot of code more readable. C2 does (will) not have the public/private stuff, but it might be good to signal a member access. This does make the case var.member and (in structfunc) _member different... Hmm

@lerno
Copy link
Collaborator Author

lerno commented Nov 27, 2018

If it was a lang from scratch I would have suggested a sigil if you wanted to access a struct member in a struct function, but that is too much of a change I think.

In JaI, ”using X” would give direct access to members in the function.

I’m two minds about this. Because having to deal with access directly emphasises the fact that one must deal with the null-pointer scenario.

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

2 participants