Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[ji] package (internal) refactoring #3754
mostly some cleanup around
... allows for pieces to stay at one place - and avoid 'hacks' such as setting
compatibility should be fine, I see too (minor) "breaking" changes :
numbers show performance is around the same if not better on some runs :
Since JavaPackage extends Module I do not see this change as one which could possibly break anything (knock on wood).
I am interested in an enumerated list of package names which would be invalid before and after the change. At a minimum, having a list like this would be great for documentation.
module JavaPackageModuleTemplate disappears from Java since it is private but you also remove the Ruby version as well. I wonder if anyone in the wild uses this (perhaps alias JavaPackage to this just in case?).
I know you did not do this based on diff but there are many method calls which are prefixed with 'this.'. If you want to kill those that would be nice.
You changed visibilty of method_missing and const_missing to private which I think is correct but I am just mentioning it in case someone knows why non-private would still be needed or could cause problems.
All-in-all I have no issues with the PR itself my only question would be to challenge which behavior could have possibly changed which will generate an issue report.
as noted in the desc it stayed the same (for now) except for :
so really only
will look into some github usage if anyone has done something of a kind. if not I'll leave it dead as is.
NP - will do, thanks.
yeah I noticed that and fixed in a follow-up commit: 744bf4e ... so this should be the same as it was.
addressed the rest and squashed some of the commits for more clarity.
UPDATE: so those are all copies of old JRuby's stdlib files - no usage found really.