dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.26k stars 1.58k forks source link

frogc doesn't work with fields on interfaces that wrap native JavaScript objects #763

Closed skybrian closed 9 years ago

skybrian commented 12 years ago

The html API generates a bunch of interfaces that are wrappers around JavaScript objects. Many of them have fields. For example:

interface AudioProcessingEvent extends Event {   AudioBuffer get inputBuffer();   AudioBuffer get outputBuffer(); }

When I actually try to use any of these fields in Dart, I get an error:

Uncaught TypeError: Object #<AudioProcessingEvent> has no method 'get$outputBuffer'

It appears that frogc is using its own calling convention (calling a method) instead of doing it the native JavaScript way (accessing a field).

(Also, shouldn't this

jmesserly commented 12 years ago

I'm guessing fields aren't using the hidden native convention.


Added Area-Frog label.

skybrian commented 12 years ago

This is likely not a real compiler issue. It's due to how I'm working around bugs in the html library. I'm not using the generated wrappers. Instead I'm using a native function to create a JavaScript object and "cast" it directly to the interface type.

jmesserly commented 12 years ago

Ah, that makes sense.

If you're using native JS, you might be able to put a block of Dart code after the native, like this: makeFoo() native "... JS code to create a Foo ..."; ...   if (false) {  // trick compiler to think AudioProcessingEvent is used:     AudioProcessingEvent e;     e is AudioProcessingEvent;     e.inputBuffer;     e.outputBuffer;   }

I'm not sure if that will work (since AudioProcessingEvent is an interface) but worth a shot.

DartBot commented 12 years ago

This comment was originally written by drfibonacci@google.com


Added Triaged label.

dgrove commented 12 years ago

Added this to the FrogEditor milestone.

jmesserly commented 12 years ago

based on comments above, I don't think this was a real compiler issue.


Added Invalid label.