<enebo[m]>
defnode happens to always be accessible in this case since it is initialize but because defnodes are methods and methods in IR are lazy I cannot ask it for flags until the IRBuild happens to real
<byteit101[m]>
as this stuff is tricky
<enebo[m]>
I know this but I realized there is a lot of assumptions here not many people realize
<enebo[m]>
implicit real super makes sense
<byteit101[m]>
oh, btw, jrubyfx is going to require we allow methods not named initialize to be the ctor (configurable per class)
<enebo[m]>
ok well however we do that the IR flag I added works for all methods looking for super use
<enebo[m]>
so long as it is a method the code we use should work more or less the same
<enebo[m]>
I am paused thinking about how to encapsulate this find super part
<enebo[m]>
The lifecycle thing I mentioned should not need to be knowledge which is coded outside the IR package
<enebo[m]>
One could argue IRScope#usesSuper() not working unless another method is called is a bug but we recently got over some epic thread safety issues with flags and this just happens to be a wart of the current codebase
<enebo[m]>
but if I encapsulate calling that within IR and possibly within IRMethod itself then this is less ugly
<enebo[m]>
In an ideal language with no memory constraints we would never make stuff lazy and it would never lead to weird stuff like that
<enebo[m]>
if I force a call to calculate within usesSuper() so it magically just works it then potentially causes weird races
<enebo[m]>
this spring all flags were based on the state of the scope but compiler passes might add/remove a flag but those flags are really just duplicated data (e.g. we can calculate them by examining the instrs) but not recording this state would be horribly innefficient
<enebo[m]>
So we migrated those sorts of flags out of IRscope and only record the universally true flags to IRScope now
<enebo[m]>
usesSuper is now a new flag which means universally that method does a super invocation (which if we inlined it then perhaps you could argue the super call is gone but we will just say the truism is that the ruby code itself calls super).
<enebo[m]>
Anyways just barfing IR impl comments to the channel is me procrastinating making a decision :)
<byteit101[m]>
enebo: just had a (questionable) idea: spaceship operator overload for 2 way bindings in javafx
<enebo[m]>
byteit101: heh perhaps. I guess example code snippets is worth looking at to see how obvious it might look
<byteit101[m]>
self.text <=> my_observable
<enebo[m]>
non-descriptive methods (special symbols) usually do not do that for me personally but perhaps it makes more sense here
<enebo[m]>
yeah I am not sure how I feel
<byteit101[m]>
no, it's very questionable, and I'm not going to implement it, but I though it looked nice
<byteit101[m]>
Kinda like dot/graphviz
<enebo[m]>
byteit101: Too bad infix operations cannot be any unicode
<byteit101[m]>
oh no, emoji!
<enebo[m]>
hah
<byteit101[m]>
I think haskell might?
<enebo[m]>
yeah I am pretty sure
<enebo[m]>
self.text 🔗 my_observable
<enebo[m]>
🔗(self.text, my_observable)
<byteit101[m]>
Error: unexpected SPECIAL in "function %😛%"
<byteit101[m]>
> function %😛%(a, b) { return a + 5 + b;}
<byteit101[m]>
R
<byteit101[m]>
oh wait, hold on
<enebo[m]>
they have cross product and a few others defined
<enebo[m]>
you can use ascii aliased names but I figured they did not hardcode those