-
-
Notifications
You must be signed in to change notification settings - Fork 357
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
Extract modules #229
Extract modules #229
Conversation
46f7920
to
ed40495
Compare
I personally like the idea of splitting the code in multiple files to have smaller pieces of code. The only concern about this is maybe that it contains too much meta programming, but current implementation has the same level of MP and I don't think is easy to avoid that. |
Thanks @fabn, yes, this is just organising the 'crap draw' basically without throwing anything away. I think because of the variable method names it's hard to avoid the class_eval stuff unfortunately. Though, there is possibly a case for using |
@brendon hopefully, |
@brendon it'd be hard to see what's changed (diff) after move to another file, so that's why I wanted to do this PR first. Also, I reconsidered |
@ledestin, that's all good. Let's stick with the current arrangement. It's my habit that when there's a group of things, I like to put them in their own place and remove any repetition around their naming if possible. Your way does read cleaner though. I'd probably use a plural for the class name if we went with that option: Merge those two classes you mentioned in your last message if you think it proper. |
@brendon we probably would have to have Going to merge. |
Thanks @ledestin. Is this ready to merge? |
@brendon I've added a small change, I came up with later. Now it's ready. |
Thanks @ledestin, I've merged this :) |
Great @brendon :) |
@ledestin @brendon @fabn This Pr induced a bug
In the stack A fix would be to split the module definition in the following pattern:
The same should be done for all the definers created in this PR acts_as_list/active_record/acts/column_method_definer |
Hi @randoum, just checking you're getting this on I remember getting a similar error due to the relative class references Can you provide an environment that triggers your bug as I haven't seen it and the suite runs green. Is it a bit random? |
Yes on master. Does not show in the tests. You should reproduce in any projects if I you to your Gemfile
Then try:
Solution is as I previously posted |
Note that you may have to load your model class in order to see the error message, so in the console for example:
|
Thanks @randoum, that makes sense. I've tweaked the load order on |
Yep, that fixed it. Cheers |
Good to hear :) |
.acts_as_list
was too long.