You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Haxe has some subtle differences from TypeScript and EcmaScript 4 (inexistent) syntax.
For aliasing types, TypeScript choose to use the context keyword type rather than a reserved word typedef. EcmaScript 4 too was going to use type (whether in ES4 it was going to be contextual or not I don't remember, though the EcmaScript 4 reference interpreter is available in archive.org).
In TypeScript, you can express Array<T> as T[]. In EcmaScript 4 you would be able to express Array.<T> as [T]. To me, it seems like the EcmaScript 4 syntax for specifying array types in brackets is cryptic and readable at the same time.
Both TypeScript and EcmaScript 4 express tuple types with the same syntax, consisting of two or more element types.
In TypeScript, the dynamic type is written any. In EcmaScript 4, it's written *.
More specifically, in these languages, type is reserved when it's followed or preceded by another identifier or reserved word, so it doesn't break compatibility.
I think it'd be interesting if Haxe supported the same ES4 syntax for clarity, considering it'd not break compatibility. It doesn't break macros, does it? After all, Haxe was inspired by ES4.
Another thing I didn't mention is that the decorator syntax of ES4 used brackets, not @:.
The text was updated successfully, but these errors were encountered:
I think supporting a multitude of styles from various languages in Haxe will mostly create confusion, but more importantly create obstacles for when we do want to add new syntax with new semantics, e.g. the * for a type param could mean a whole bunch of things other than Dynamic that might have distinct use cases.
I see some value in supporting ECMAScript syntax. The advantages of using standardized syntax are quite obvious and Haxe did start out being advertised ECMAScript dialect. It diverged from its heritage for a whole bunch of good reasons, but there's been a whole lot of parallel evolution, where there's little value in Haxe having a different syntax than ES/TS do. If anything, I think a separate frontend for an ECMAScript aligned syntax would actually be relatively useful, but I don't see the work involved (especially with IDE support) paying off.
Haxe has some subtle differences from TypeScript and EcmaScript 4 (inexistent) syntax.
type
rather than a reserved wordtypedef
. EcmaScript 4 too was going to usetype
(whether in ES4 it was going to be contextual or not I don't remember, though the EcmaScript 4 reference interpreter is available in archive.org).Array<T>
asT[]
. In EcmaScript 4 you would be able to expressArray.<T>
as[T]
. To me, it seems like the EcmaScript 4 syntax for specifying array types in brackets is cryptic and readable at the same time.any
. In EcmaScript 4, it's written*
.More specifically, in these languages,
type
is reserved when it's followed or preceded by another identifier or reserved word, so it doesn't break compatibility.Here's a Haxe version:
Here's an EcmaScript 4 version:
I think it'd be interesting if Haxe supported the same ES4 syntax for clarity, considering it'd not break compatibility. It doesn't break macros, does it? After all, Haxe was inspired by ES4.
Another thing I didn't mention is that the decorator syntax of ES4 used brackets, not
@:
.The text was updated successfully, but these errors were encountered: