Allow @JS on class method

[a14n]

Unlike top level function putting @JS on a class method has no effect.
A use case where it is needed is to make a Js member named _m1() on A be used outside of the current dart library.

@JS
class A {
  external A();
  external _m1();
} 

I'd like to be able to have:

@JS
class A {
  external A();
  @JS('_m1') external m1();
} 

[jacob314]

you need a custom interceptor to support custom names for individual member methods.
That would hurt dart2js code size and is impossible if class A is anonymous.

We will provide a general scheme to expose js private methods and cases where the JS name is not accessible from Dart.
Generally, any 1-1 mapping between Dart names and JS names is fine. A strawman is prefix the method name with JS$ to support js names that aren't valid names
So for example
JS$_m1()
will call
m1() in JS

The common use case would be methods with illegal dart names. For example
JS$get() would map to the JS method get()

if you ever need to actually access the js method JS$Foo you would have to write JS$JS$Foo to escape.

[kevmoo]

@jacob314 should this be closed? Or do you want to keep it as a place-holder for other work?

[a14n]

@jacob314 could you explain how those JS$_m1() will be handled? I can't figure out what makes it really different from treating a @Js() on methods. Is it problematic only in dart2js or also on dartium ?

[jacob314]

The main key is there needs to be a single consistent mapping across all JS
interop classes for names that are rewritten. Any naming scheme that
guarantees a consistent mapping between JS and Dart type names is fine.

methods named
$JS$_ml() are always rewritten to _ml()
regardless of the class so that is fine.

you would get in trouble if you have
@js('_m1') external m1()

and
@js('m1') external m1()
in a different class.
Now the code invocation needs to differ based on the actual type which
blows up a system where you don't need to know the specific JS type to know
how to invoke a method.

On Thu, Nov 5, 2015 at 12:56 AM, Alexandre Ardhuin <notifications@github.com

wrote:

@jacob314 https://github.com/jacob314 could you explain how those
JS$_m1() will be handled? I can't figure out what makes it really
different from treating a @js() on methods. Is it problematic only in
dart2js or also on dartium ?

—
Reply to this email directly or view it on GitHub
#24779 (comment).

[jacob314]

Reassigning and changing the area as this is really a dart2.0 language feature request.

[a14n]

Awesome !!!

Is there also a feature request to allow non external method in @JS annotated class ?

[jacob314]

If it happened to be implemented with extension methods than you could essentially add arbitrary non-external methods to @js classes as long as the type is statically known at invocation time.

[munificent]

Can you give some more details on what the language-level request is for this?

[a14n]

Does the death of Dartium and the soundness changes in Dart 2 change something to this issue ?

It would be really awesome to have this feature to provide darty libs on top of JS libs.

[jacob314]

Dart2Js needs to start taking advantage of the Dart 2 type system and then this feature is feasible.

[a14n]

Not sure that it's covered by this issue but does having concrete methods in a @JS class be also possible ? Being able to do something like the following snippet would be a great improvment:

@JS('google.maps.Map')
class Map {
  LatLngBounds get bounds => _getBounds();
  @JS('getBounds') LatLngBounds _getBounds();
}

[jacob314]

Yes. I believe if you have one feature the other feature is pretty easy to implement.

[leafpetersen]

Is this still a language request? If so, what's the request? Something like extension methods?

[a14n]

This is a request to improve JS-interop. As Dartium is now dead I think this can be implemented directly in JS backends. So I don't think extension methods are still needed.

Someone let me know that some JS-interop improvements were on the road. Any news about that and what to expect?

[jmesserly]

this is important to address as part of improving JS interop (#35084)

[natebosch]

I think https://dart-review.googlesource.com/c/sdk/+/88020 was intended to solve this.

Unfortunately we're blocked on moving forward unless we can also solve it in dart2js which is more difficult. Nothing will change for now.

[sigmundch]

This is now supported as part of the new interop based on dart:js_interop. See https://dart.dev/interop/js-interop