<enebo[m]>
Is it possible that an inspect on various packages may still display as Java::Package?
<headius>
Maybe? I started to try to make packages a bit more normal but they are very tricky
<enebo[m]>
headius: if you look at my comment after that Java::Package does not think it is_a? Class so I am pretty confused what is happening
<enebo[m]>
This is almost mor of a curiousity at this point too since I believe superclass on this single Module will not be the only problem we have with sorbet since it binds like 6 other methods but it is so odd I kind of want to figure ito ut
<headius>
We really need a sort of blank slate module
<headius>
I will look at issue
<enebo[m]>
I also think sorbet probably needs some robustness here since any Ruby class can remove any of the methods they assume will exist
<enebo[m]>
That obviously is a really odd thing to do but it is possible
<enebo[m]>
lol...sometimes the longer the time I spend on something the more obvious the answer will be once I realize what is up
<headius>
I just got into the guts of packages, what did you find?
<enebo[m]>
JavaPackage is actually a class
<headius>
yeah that was what I suspected from your comments
<enebo[m]>
This was what sent me down the rabbit hole
<enebo[m]>
so we make a class but set the metaclass to be module
<headius>
hmm
<enebo[m]>
You can see it right above in that snippet :)
<enebo[m]>
My first debug was to print out the .class value where it blows up..."Module...how the fuck is that happening?"
<headius>
hmm yeah
<enebo[m]>
So we made it a class to instantiate it and it will be a BlankSlate but we wanted :: so we made it a module
<enebo[m]>
well classes would allow that
<enebo[m]>
hmm
<enebo[m]>
I wonder what happens if I remove the setMetaClass :)
<headius>
I am not sure why we need these to be Class instead of Module... I guess because they have a superclass?
<enebo[m]>
or we use some form of new internally?
<enebo[m]>
seems like we can make a new module simply enough too though
<headius>
my initial attempt to improve this was flawed because I tried to use BasicObject, but for :: we need it to be a module or class
<headius>
switching it to module might work
<enebo[m]>
Seems like BlankSlateWrapper could be a module and not a class
<enebo[m]>
actually I guess I see you want the module to be whatever it is but all method delegation to metaclass you want to be a blankslate
<headius>
making the JavaPackage class into a module gets messy
<headius>
it is expected to be a RubyClass along several call paths
<enebo[m]>
yeah this is pretty confusing. I might for fun just add a hacked superclass to see what breaks next
<enebo[m]>
I am certain we will hit more method issues
<enebo[m]>
LOL
<enebo[m]>
We cannot just add a superclass since this asks for an unbound method off of class but because we mark the packages metaclass as module bind fails because it thinks it is not a class
<headius>
I still can't see why it needs to be a class other than we propagate instances of it as RubyClass everywhere
<enebo[m]>
yeah but there has to be some reason :)
<headius>
dig up Bill Dortch and ask him
<enebo[m]>
does it go back that far? I figuer this used to be all in Ruby so this had to be after we started pushing into Java
<headius>
when it was all in Ruby I don't think we had this functionality
<enebo[m]>
I thought we could always java.awt.Color as a syntax
<headius>
hmm looks like this logic in JavaPackage was from kares
<enebo[m]>
I think it used to just be a method_missing
<headius>
I know we added that after I started on the project but I don't remember when
<headius>
it was not there before
<enebo[m]>
I see it switch from .inherit to the setMetaClass
<enebo[m]>
I guess my only point was I thought we had a method_missing version of package in Ruby before we moved to Java
<headius>
yeah this commit from kares moved the package template from Ruby into Java in 2015
<enebo[m]>
which would not have had this platypus of a thing