These are chat archives for opal/opal

15th
Jan 2016
Brady Wied
@wied03
Jan 15 2016 16:08
For those interested in running opal-rspec specs in Karma, here is another option - https://www.npmjs.com/package/karma-opal-rspec
Brady Wied
@wied03
Jan 15 2016 16:46
Was (officially) released today
Elia Schito
@elia
Jan 15 2016 16:48
:clap:
Ilya Bylich
@iliabylich
Jan 15 2016 17:43

@meh Is there any chance to fix Float.===? Right now it returns true for any number.
Writing something like

class Float < Numeric
  def self.===(other)
    %x{
      if (!other.$$is_number) {
        return false;
      }

      return (other % 1) !== 0;
    }
  end
end

breaks floats coersion (i.e. 1.to_f returns a Number and Opal.coerce_to! throws an error)

meh.
@meh
Jan 15 2016 17:45
iliabylich, nope
iliabylich, all numbers are float in js
Ilya Bylich
@iliabylich
Jan 15 2016 17:49
@meh I see, thanks
meh.
@meh
Jan 15 2016 17:49
they're actually double, but you get the point
Ilya Bylich
@iliabylich
Jan 15 2016 18:48

@meh How about wrapping each float on the compilation stage to Float(number) and modify Kernel#Float to:

def Float
  %x{
    float = (... previous code ...);
    float = new Number(float);
    float.$$is_float = true;
    return float;
  }
end

Then Float.=== may look like:

def self.===(other)
  return (other.$$is_float) || ((other % 1) !== 0);
end

Plus some changes in Math logic like

def *(other)
  if Float === other
    Float(self * `#{other}.valueOf()`})
  else
    # current logic
  end

After theses changes we will get only one difference with MRI: inline number.0, because it's not a compiled number and it doesn't have floating value. What do you think about it?

meh.
@meh
Jan 15 2016 18:48
then you can't just pass a float to JS functions
and it adds overhead
and you can't do what you did
ah wait, you can
but yeah, they're not literals
object literals are way different from literals
typeof new Number(2)
'object'
typeof 2
'number'
Ilya Bylich
@iliabylich
Jan 15 2016 18:49
@meh Yes, but you can check it in the code
meh.
@meh
Jan 15 2016 18:50
not on native JS code
then you'd have to call #to_n
it just adds pain for not much advantage
Ilya Bylich
@iliabylich
Jan 15 2016 18:52
Why not much? It allows you to completely split Integer values from Float
meh.
@meh
Jan 15 2016 18:52
iliabylich, yes, and what's the practical advantage to that?
Ilya Bylich
@iliabylich
Jan 15 2016 18:52
And I don't get where's the problem with native values
meh.
@meh
Jan 15 2016 18:53
iliabylich, object literals behave differently from actual literals
it just makes interaction way harder
Ilya Bylich
@iliabylich
Jan 15 2016 18:56
There's a difference between some MRI method implementations depending on the passed object. For example, Range#step behaves in a different way when you pass float/integer
meh.
@meh
Jan 15 2016 18:57
I'm aware of that, but full compliancy in this regard just adds overhead
and besides
Ilya Bylich
@iliabylich
Jan 15 2016 18:57
I'm not sure are there any other methods like this, but all of them can't be fully implemented until Floats are Integers
meh.
@meh
Jan 15 2016 18:57
all you have to do is check for Integer first
and Float after
Integer will return true only when there's no decimal part
Ilya Bylich
@iliabylich
Jan 15 2016 19:05
Yeah, you are right, the only advantage that it gives is (partially) correct implementation of Float.=== (which can be simulated by calling !(Integer === number) && Float === number). I thought that it may allow us to define float logic directly on the Float class, but there's no sense to do that
meh.
@meh
Jan 15 2016 19:07
@iliabylich to be clear, I know it's a huge pain in the ass, when I was working on Numeric compliancy I thought about it for a long while, but the cons are more than the pros
Forrest Chang
@fkchang
Jan 15 2016 19:43
@wied03 good job, I'll have to check it out