Just my personal thoughts on this.
The way PHP migrated to types has been thought incremental steps, and it
worked pretty well.
Since types have been demanded by the JS community for a while, I think
it'd be key to approach JS types not all at once, but through smaller
iterations.
As example, a proposal with a whole section entitled "Other useless things"
would easily diverge focus to stuff the is really not necessary at this
point.
Since types are also pretty much only a tooling convention, starting just
with the most basic need/help, and iterate more complex cases later on,
would be probably the best way to go.
Reading though all suggestions, I personally think these would be a no
brainer to specify and ship as first iteration:
- primitives mean primitives (i.e. `string` means `typeof "string"`, no
strings attached)
- Classes and Built-ins mean classes and built-ins (i.e` String` means
any `instanceof String`)
- enum could be a new primitive (as in `typeof "enum"`, since static and
immutable) but also an expression (like classes), for enums defined as
properties/fields of literals and classes
- I actually like the `auto` name more than `any`, but without signature
overloads/rides the use case would be too broad, so that maybe we should
have a way to also define multiple types (i.e. `const notFullyAuto:
String|Object|string = value;`)
- while I know it's pretty common to have `number[]` as type to define
an array of numbers, I also don't understand why a new syntax should have
already two different ways to define typed array, i.e. `const
list:number[]` and `const list:[number]`, so since the latter one is more
powerful/flexible, to define also multiple key/value pairs, maybe that's
all we need
With these basics, the JS world would already have a huge change.
Things we might consider, but me might also don't care about, since these
behaviors are part of the specs:
- `object` would accept `null`, but since there is no `typeof "null"`,
the way to ensure `null` won't be there is to use `Object` instead. Are we
OK with that?
- `number` would accept `NaN` and `-/Infinity`, but IMO that's the case
also without types, if a number is expected. Are we OK with that?
- to avoid confusion with binary `|` operations, maybe multiple types
could be wrapped in brackets, so that `const index:{number|string}` might
look better?
That's it for my idea on how this could start moving forward.
Best Regards
On Sat, Mar 23, 2019 at 9:37 PM IdkGoodName Vilius <
[email protected]> wrote:
> This is a proposal for static typing. Here is the github repository link:
> https://github.com/CreatorVilius/Proposal-Static-Typing
> I think it would be great thing in JS.
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
