Skip to content
This repository has been archived by the owner on Feb 2, 2024. It is now read-only.

Compat classes don't seem to work with modular-js #9

Open
jcward opened this issue Aug 31, 2017 · 2 comments
Open

Compat classes don't seem to work with modular-js #9

jcward opened this issue Aug 31, 2017 · 2 comments

Comments

@jcward
Copy link

jcward commented Aug 31, 2017

This issue is related to these lines of code (was this in Haxe 3.4.2) in the compat classes, perhaps these existing Haxe issues (6491, 4467), maybe these people (@nadako @andyli @elsassph @kevinresol @MatthijsKamstra) would have some ideas, and this testcase:

class Test {
    static function main() {
        var b = haxe.io.Bytes.ofString("hello world!");
        trace(b.toString());
    }
}

Without modular-js, just the default JS generator and Haxe 3.4.2, the above testcase generates this code. That's all well and good, though the var Uint8Array on line 442 does something interesting. It overrides the global Uint8Array for the scope of the whole file, and doesn't set it until execution of that line. It doesn't happen to be a problem with the default JS generator.

But now, consider the output when using modular-js. The output js/html/compat/Uint8Array.js file is here. By definition, this can't work, because the var Uint8Array at the bottom. In this scope, Uint8Array is a null reference until that line executes, so the first line in the scope (Uint8Array.BYTES_PER_ELEMENT = 1) is a null reference. Not only that, declaring a var Uint8Array in this file does not effectively override the global scope (which I believe is the intent / effect of the default JS generator.)

I'm not sure what needs to change -- the modular-js generator, or this line in the compat files in the standard library. But since this issue is currently specific to modular-js, I filed it here. (BTW, @elsassph, I wanted to see what happens in haxe-modular but couldn't get it to work. After installing the npm lib and haxelib, running the testcaes I got sh: 1: haxe-plit: not found)

First, is the idea behind the compat files this: a polyfill for browsers without Uint8Array / DataView / ArrayBuffer / etc? Second, is it a good idea for the compat files to declare a var in untyped __js__, much less a var name that overrides a (browser) global?

Thoughts?

@elsassph
Copy link

elsassph commented Aug 31, 2017

Effectively modular-js needs to make this compat definition global or required where needed. HaxeJS normally expects everything to be in one anonymous scope so it works. Haxe-modular does what is needed to make the compat definition accessible.

@jcward
Copy link
Author

jcward commented Aug 31, 2017

@elsassph Got it, thanks for the info (and the tweet replies)! I currently have a workaround in my build system, but it'd be nice to have a solution built into modular-js. I'll update if I think further about this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants