Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow @JS on class method #24779

Closed
a14n opened this issue Oct 30, 2015 · 17 comments
Closed

Allow @JS on class method #24779

a14n opened this issue Oct 30, 2015 · 17 comments
Assignees
Labels
area-web Issues related to Dart Web. web-js-interop Issues that impact all js interop

Comments

@a14n
Copy link
Contributor

a14n commented Oct 30, 2015

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
Copy link
Member

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
Copy link
Member

kevmoo commented Nov 2, 2015

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

@kevmoo kevmoo added the web-js-interop Issues that impact all js interop label Nov 2, 2015
@a14n
Copy link
Contributor Author

a14n commented Nov 5, 2015

@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
Copy link
Member

jacob314 commented Nov 5, 2015

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).

@kevmoo kevmoo added closed-not-planned Closed as we don't intend to take action on the reported issue and removed resolution-wont_fix labels Mar 1, 2016
@jacob314 jacob314 added the area-language New language issues should be filed at https://github.com/dart-lang/language label Jul 7, 2016
@jacob314
Copy link
Member

jacob314 commented Jul 7, 2016

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

@jacob314 jacob314 removed the closed-not-planned Closed as we don't intend to take action on the reported issue label Jul 7, 2016
@a14n
Copy link
Contributor Author

a14n commented Jul 8, 2016

Awesome !!!

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

@jacob314
Copy link
Member

jacob314 commented Jul 8, 2016

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
Copy link
Member

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

@a14n
Copy link
Contributor Author

a14n commented Dec 4, 2017

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
Copy link
Member

jacob314 commented Dec 4, 2017

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

@a14n
Copy link
Contributor Author

a14n commented Dec 4, 2017

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
Copy link
Member

jacob314 commented Dec 4, 2017

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

@leafpetersen
Copy link
Member

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

@a14n
Copy link
Contributor Author

a14n commented Jun 6, 2018

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?

@lrhn lrhn removed the area-language New language issues should be filed at https://github.com/dart-lang/language label Jun 25, 2018
@jmesserly jmesserly assigned jmesserly and unassigned leafpetersen Jan 2, 2019
@jmesserly
Copy link

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

@natebosch
Copy link
Member

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.

@vsmenon vsmenon added the area-web Issues related to Dart Web. label Jul 22, 2019
@sigmundch
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-web Issues related to Dart Web. web-js-interop Issues that impact all js interop
Projects
None yet
Development

No branches or pull requests

10 participants