Bridging syntax (class ... < ...) is confusing #2216

This is because bridging works with JavaScript classes (i.e. constructor functions), and even in that case the syntax would be:

class Test < `window.constructor`
  def foo; 123; end
end

win = `window`
win.foo # => 123

In Ruby the only thing that you can extend are classes, and that holds true in Opal.

I'm closing this to keep the issues tidy, but feel free to reach out in the slack channel o on stack overflow (tag opalrb) for more help on how to handle native objects and inheritance.

PS. I didn't test the code above, consider it just demonstrative

There are several issues.
Firstly I want to create a child class of Native class (ie. extra methods added) of JavaScript object, not extend JavaScript object itself.
For example

class MyWindow < Native(`window`)
  def self.url
    location.href
  end
end

MyWindow.url # => "https://github.com/opal/opal/issues/2114"

The main issue here is that Native is an instance of Native::Object (which is BasicObject) and not a Class.
Here Opal has a bug #2123 that it fails with JS error instead of saying that.
Anyway I'm working on implementing that my example works as provided, I've almost finished that.

As for

class Test < `window.constructor`
  def foo; 123; end
end

This does opposite, it changes original JS object, not creates a subclass and it works only for some objects. It doesn't work for window. It fails with Uncaught TypeError: can't set prototype of this object
Because browsers doesn't allow to change some prototypes

> Object.setPrototypeOf(window.constructor.prototype, Object.create(null))
Uncaught TypeError: can't set prototype of this object

Also I find this syntax to be very counterintuitive. I don't see why Opal couldn't have used more straightforward way of

class `Window`
  def foo; 123; end
end

which makes a lot more sense and is clearer/readable.

class MyWindow < Native(`window`)
  def self.url
    location.href
  end
end

MyWindow.url # => "https://github.com/opal/opal/issues/2114"

For this use case I think the best approach would be changing the singleton class of the Native wrapper:

$window = Native(`window`)
class << $window
  def self.url
    location.href
  end
end

Also I find this syntax to be very counterintuitive. I don't see why Opal couldn't have used more straightforward way of

class `Window`
  def foo; 123; end
end

I agree with this, using the subclass syntax for bridging is not the best option, the problem with using the backticks directly is that class wants a name, while the backticks contain an expression, a better option may be to always do the bridging in a separate step, like it's done for Number:

class Number < Numeric
  Opal.bridge(`Number`, self)
  ...
end

what do you think?

$window = Native(`window`)
class << $window
  def self.url
    location.href
  end
end

Hadn't thought about this and it actually works but there is downside.
It's not possible to create new instance, consider if we want use some instance parameters.
Of course we could create a wrapper, but that wouldn't be Ruby'ish.
Eg. MyWindow.new(param) vs Factory.getWindow(param)
Also it's not as pretty :D
I think my solution in #2132 works pretty good.

class Number < Numeric
  Opal.bridge(`Number`, self)
  ...
end

This is definitely better but I think removing support for current way is not really realistic because of already existing code which does it that way.