Closed sirisian closed 5 years ago
Very rough changes: https://github.com/sirisian/ecmascript-types#interfaces
I modified the destructuring object return syntax to use the interfaces syntax with a semicolon.
I need to write more examples for all the nested examples and use cases and what it looks like when they're expanded.
My current thinking is that ES at some point might support named arguments, so I don't want to create a syntax where that constraint can't be applied. That is the programmer should be able to say 'This code requires a function where the second parameter is named "foo" and then call it by name.' That might not be necessary as long as the Interface names the parameter though. That is the code will find the location of the parameter in the Interface and not check the actual passed in function, just the types.
This might be unintuitive, but if I change the syntax for function interfaces from:
interface IExample
{
(:string = 5, named:uint32):void;
}
To:
interface IExample
{
(string = 5, uint32:named):void;
}
Basically a function signature looks like function F(a:uint8) {}
but an interface signature would look like interface IExample { (uint8:a); }
. The vast majority of times the user would not write parameter names, so this seems fine. This also makes regular function types intuitive and allows optional names.
let a:(uint8:a) = a => a;
I'm thinking of using this convention in the proposal unless someone has a better idea.
I changed to the new function interfaces syntax. Also added some extending examples for object and function interfaces:
https://github.com/sirisian/ecmascript-types#interfaces
I'll probably close this when I add the examples with classes.
The more I think about it interfaces as in TS: https://www.typescriptlang.org/docs/handbook/interfaces.html are looking more and more useful from a programming perspective. It's one of those features where people can program without them, but when they are added and syntax is chosen people will go back and add them in or refactor code.