add haxe.EitherType (see HaxeFoundation/hxnodejs#15)

[nadako]

No description provided.

[nadako]

@waneck proposes adding left:T1 and right:T2 methods/properties to the abstract so one could extract the value of proper type without explicit casting. Should we add that? I think this could be quite useful.

[Gama11]

Wouldn't first and second be more appropriate? There's not really anything that indicates a "direction" here, but via T1 and T2 the types basically already have a number.

[andyli]

About left/right prop, I'm not sure if it is a good idea, since I think casting would be more readable.

var value = someFunction().left; //what is the type of value?
var value:Int = someFunction(); //ok, it is an Int

//nested EitherType
var value = someFunction2().left.left.right; //what?

Also since this is mainly used for extern, and nowadays we used to generate them from doc. It is possible the order of T1 and T2 are inconsistent.

@:overload(function(v:Int):EitherType<Int, String>{})
public function fun():EitherType<String, Int>;
/* ... */
$type(fun().left) //String
$type(fun(123).left) //Int

[nadako]

Hmm, that's a valid argument, @andyli. I thought simply using left/right would be cleaner, but now looking at the actual code I see that it just causes confusion, especially with nested types.

[nadako]

Merging it as is.

[ncannasse]

Could we shorten it to Either only ?

[nadako]

@ncannasse see HaxeFoundation/hxnodejs#15 (comment)

[frabbit]

Couldn't we move it in a subpackage like 'haxe.externs' to make clear that its a helper class for externs? Btw. I like the name Choice for it.

[Simn]

That's an interesting idea, it could live next to haxe.Rest and perhaps even ArrayAccess.