HaxeFoundation / HaxeFoundation/haxe
[js] enum-as-object cleanup wishlist
- Dominant language
- Haxe
- Stars
- 6.9k
- Forks
- 715
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 11
Description
So I diffed the output with the new object-based enums and it looks great, however it increases code size in real-world cases quite a bit and I think we can do something about it:
```haxe
enum E {
A;
B(v:Int);
}
```
generates
```js
var E = { __ename__ : true, __constructs__ : ["A","B"] };
$hxEnums["E"] = E;
E.A = {_hx_index:0};
E.A.toString = $estr;
E.A.__enum__ = "E";
E.B = function(v) { var $x = {_hx_index:1,v:v,__enum__:"E"}; $x.toString = $estr; return $x; }
E.B.__params__ = ["v"];;
```
could be optimized to
```js
var E = $hxEnums["E"] = { __ename__ : true, __constructs__ : ["A","B"] };
E.A = {_hx_index:0, toString: $estr, __enum__: "E"};
E.B = ($_ = function(v) { return {_hx_index:1,v:v,__enum__:"E",toString: $estr} }, $_.__params__ = ["v"], $_);
```
Basically we don't want to repat the type/ctor name too much because in real code it would be something like `rambo_ResourceChangeReason.ClanwarAttackMaterialPurchase`.
---
Another thing that makes me uncomfortable is the naming inconsistency here. We have `_hx_index`, but also `__enum__` and `$hxEnums`. I feel like it would be better to use the `$ident` scheme for everything as this would also exclude the possibility of name clashes coming from weirdly-named identifiers in Haxe code.
So something like `E.A = {$enum: "E", $index: 0, toString: $estr};`. I think it would also look better when using the enum objects from plain JavaScript, as the `$`-fields look like special tag fields while non-`$`-fields contain data.
---
Thoughts?
Contributor guide
Assessment
This issue has not been assessed yet.