HaxeFoundation / HaxeFoundation/haxe

[js] enum-as-object cleanup wishlist

Open
#7,165 8 comments 0 reactions 1 assignee Claimed by @nadako View on GitHub
enhancement platform-javascript
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.