-
Notifications
You must be signed in to change notification settings - Fork 7
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
Class Commons "2.0" #5
Comments
I both love and hate this idea! On the one hand, it's so much less messy than globals. 😃 On the other hand, this seems to suggest you could do On the third hand, I can't think of a better place to hide the commons, so yeah. 👍 |
I don't have a strong opinion on this. On the one hand, the current spec works and you know what they say about how often to change a running system. On the other hand, hiding |
Hello guys, I have a proposal for ClassCommons 2.0. Regards, |
To keep it all central, I'll comment in this ticket:
|
Hello Barbes, At first, I was sad to read your comment. I only see "I'm not a fan", "I'm not sure", "In fact ... is exactly what ... trying to prevent". But now, I understand my goal seems very different from your one with ClassCommons2. Regards, |
I was worried I was too negative, but I chose to be honest about my concerns, rather than sugarcoat it, and I'm glad you took it well. It seems your goal doesn't align with Class Commons, but it is definitely an interesting one. Good luck with your project! |
I think there is one common point between ours both goals : using local/module environment instead of global one. |
Class Commons has been fixed for a while now, and perhaps it's time to shake it up a little, fix our grievances, and clean it up.
I had some ideas regarding a new, cleaner interface. In particular, the ugliest wart of Class Commons, in my opinion, is that it relies on globals. I have devised a way around this, but it also has this wonderfully hacky feel to it, so I welcome all feedback.
If anyone else has ideas, or proposals, please do share, I think we should generally strive to keep the specification as stable as possible.
Without further ado:
package.loaded["class.commons"]
, if it does not exist it provides it, as if it were thecommon
table from before.pcall(require, "class.commons")
to find its implementation.This means we can get rid of both globals, and package.loaded/require are used as direct replacements.
The text was updated successfully, but these errors were encountered: