-
Notifications
You must be signed in to change notification settings - Fork 136
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
Keys namespace #349
Comments
SGTM. |
SGTM. I'll submit a PR soon if no-one does it by the time I'm free. |
Cool! I would do it but i'm on the tutorial PR ehehe |
Doing this would require to either move the keys to a new package called keys or create a struct called Keys. Personally, I'm for placing them in a new package. This way we can make them a const so users can't edit them. One thing to note is that it would become keys.W instead of engo.Keys.W. I wouldn't mind making a PR myself unless @otraore has started on it. |
I would think this is something we'd want to achieve, yes. |
I like this. Also makes it more 'part' of Engo, if that makes any sense. The only thing we would have to keep in mind is that it could become too congested. |
I still would namespace. When you |
I think like @Sendoushi it shouldn't polute the global |
Bringing this issue up again, thoughts? |
I'm with my proposal |
I'm going to assume you meant to write engo.Keys? |
Yes. I did. |
As mentioned before, these values need to be const to avoid problems and to allow the compiler to inline them when needed. Golang does not provide a way to namespace const values in to |
For reasons mentioned by @Nitya-dev I think |
And as an added bonus, they would all be constant where possible. Instead of set within an |
I created a poll here so we can vote on either one http://goo.gl/DHniyG. Also @Sendoushi if we do use engo.Key.W that means that 'Key' would be a struct with no support for constants. |
|
As of this moment, each key is under the same general namespace. So if you want the
w
key, you would getengo.W
.My proposition:
Namespace so we could get it with
engo.Keys.W
. This way we wouldn't "dirty" the general namespace and it would be easier with an IDE for example to understand what thatengo.W
means.The text was updated successfully, but these errors were encountered: