search

HaxeFoundation / haxe-evolution

Repository for maintaining proposal for changes to the Haxe programming language
111 stars 58 forks source link

Allow enums to opt-out of publishing their constructors in the implicit global scope. #83

Closed 0b1kn00b closed 2 years ago

0b1kn00b commented 3 years ago

There's a couple of design principles underlying this that I'll go into if there is any interest. Rendered version

0b1kn00b commented 3 years ago

Say a real world example: socket protocol. Typically you want something you can put over the wire, so rather than an interface, you use nested enums to describe the various bits and you can wrap as you step up the abstraction layers. It looks to break down (atm) into local client, remote client, local server, remote server as functionality goes, each with a slightly different input set.

Queue masses of faffing with conventions LocalServerRequest containing LSR_Open, RemoteServerRequest containing RSR_Connect or whatever.

It works, but it's less than elegant, so that's really the basis.

Aurel300 commented 3 years ago

I have been in the past affected negatively by certain rules of the name resolution system. But I feel that this solution is a bit of a hacky workaround, when really the "proper" solution would be to rethink that system in the first place (addressing more than just enum constructors).

0b1kn00b commented 3 years ago

I don't disagree with that necessarily, I'm just not sure there is any way of doing it without breaking stuff.

My view of this here is that the workarounds are nasty, so I thought I would flag it

0b1kn00b commented 3 years ago

I think in the Nom, which is a Rust parser framework, there is an operator to clear the scope. Would that be a better way of looking at it?

Simn commented 2 years ago

lean-reject: weak proposal, questionable benefit

Simn commented 2 years ago

We have rejected the proposal in the haxe-evolution meeting today.

The proposal addresses a valid concern, but the way it aims to solve it doesn't seem optimal. We agree that it would be useful to "hide" enum constructors in some cases, but this would have to be designed in a broader manner. Also, there's concern that any such feature should be accessible on the import-site, not just in the type definition.