-
Notifications
You must be signed in to change notification settings - Fork 56
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
lua: add sj.get_modules #252
Conversation
Looks like a good start... any chance to add few tests? :)
I will do deeper review of the code later when working on merge on this to think about further edge cases and to implement these if nobody else does, but I appreciate any effort trying to get the ball rolling, thank you. |
results: |
Really better than sj.get_module_namespace()
I think the function should return the full namespace; it's easy to split on dots if needed. The function should then just be renamed sj.get_namespace()? |
It returns the full namespace, but only for modules, so the function will be sj.get_modules() |
any further plans to change this or why is it still in "draft"? After very quick overview this seems to me good enough to review thoroughly and merge, I didn't spot anything missing. Or are you waiting for the windows stuff fixed? I will try in following days, but no promises. But also this doesn't really depend on that. :) |
No, you can review and merge (if it's good enough ofc). |
Wait a second, why does not I see a reason why it was stripped of extra arguments depending on internal implementation around v1.20.0 and more flexible API bridge exposing those, but I'm failing to see logic behind the behavior: label string is not processed as usual but used verbatim as is The current docs are not going into such details so their description could fit any implementation (it just does specify it's regular label, so you can't redefine it in the same pass, etc). IMO this is bug and the sj.insert_label should be fixed, so the module namespace will be added automatically when the LUA script is running inside module. That doesn't invalidate this new addition, just does modify results of the tests (which I will patch). @fmafma - let me know if you see some issue with such fix and disagree about the idea (whether it breaks your current projects - I'm sorry, but I would prefer to rather have it working in "right" way and fix your projects, but I'm wondering if it's only me considering current behavior "wrong"). Also the current tests fails on two asserts because of what insert_label exactly does... :D ... but that's not the point of get_modules test, so I will patch that too. All that said, it's almost perfect PR saving me ton of "thinking" time being indecisive about this and that, it's lot more easier to ponder about solid proposal and eventually patch 2-3 lines than starting from scratch. Amazing work @lordheavy , thank you. |
I have no problem to adapt my code to the correct behaviour of this fix! Thank you both for this nice addition. BTW, I was wondering if in a future revision (2.x?), MODULE should not be replaced by NAMESPACE (NS)? This way, one could use it to create sub-namespaces. Of course, it can be done right now by stacking MODULE blocs, but it is less intuitive that NS. Just a though. Maybe just add NS alias to MODULE? |
merged with small test adjustment |
Maybe naïve, but it works mostly fine.