<headius>
hmm this replace-does-not-rehash spec may not be compatible with our hash hierarchy
<headius>
the CRuby logic directly copies the hash guts over so no #hash calls are needed to replace
<headius>
but we have hashes with other types of guts
<enebo[m]>
hmm
<headius>
enebo: yeah so I can fix this but it seems gross
<headius>
basically needs to only copy RubyHash guts if both this and the other hash are natural RubyHash and not a subtype that might use different guts
<headius>
so getClass() == RubyHash.class kind of check
<headius>
it's bad OO but so is subclassing RubyHash and using completely different guts
<headius>
that's how we simulate a RubyHash for a Java Map
<headius>
replaceWith override is necessary if you don't have the same guts, or else the logic needs to check two getClass()
<headius>
the copying replace should be faster of course, so there's not just a compatibility question
<headius>
I've wanted to untangle this hierarchy for a while
<enebo[m]>
I do wonder what uses this new identity hashing
<enebo[m]>
I suspect Rails might
<headius>
so this is basically doing a double dispatch to ensure guts can be copied
<headius>
I propagated this change to the other ident stuff and it fixes the JI failure now
<enebo[m]>
It is amusing to see people say, "those people were not needed at twitter. It is still running fine". Try firing 80% of the workers at a nuclear power plant by your house and see how sound that logic is
<enebo[m]>
oh I only bring up this topic because I requested an archive of all my tweets. I put that off but I should have did this a week ago. If people care about keeping a history of tweets I would not take any chances
<headius>
funny I just did that too
<headius>
ok I pushed my fix, have a look and let me know if it is too gross or fragile
<headius>
only alternative is regressing some of the things I fixed, until we can untangle this logic
<enebo[m]>
headius: I think that is ok
<enebo[m]>
I know what you mean on == being potentially a problem later on if we decide to change something about how we make a Hash
<enebo[m]>
I think if something like that does happen this will just be one problem of many to fix
<headius>
yeah there's just no way for us to implement the Java Map subclass of RubyHash without doing this
<enebo[m]>
yeah nothing holding them together except Map itself
<headius>
this could be a more OO visitor sort of pattern but then I think subtypes would have to override more stuff
<headius>
in any case this whole hierarchy needs to be reworked so I don't think it's worth patching around it too much right now
<enebo[m]>
other than exact object equality check I don't find this pattern all that odd in our codebase
<enebo[m]>
but a big issue with Java is tying two disparate types together into a common one
<headius>
if we had had default methods in Java years ago it might have made sense to have all Ruby types bound to interfaces, so they could be implemented many ways without inheritance
<enebo[m]>
sure
<headius>
then we could have had RubyHash be final and know its guts would always be the same
<enebo[m]>
in 5 minutes we will be discussing multimethods
<enebo[m]>
It took me almost 2 hours to solve this ripper heredoc issue.
<enebo[m]>
Most fixes have not been that difficult.
<headius>
hah
razetime has quit [Remote host closed the connection]
<headius>
ENV is green
<headius>
took longer than expected because our kwarg extract functions are gross