Ideas on type hinting and named parameters

Jeff Morrison lbljeffmo at
Wed Jun 10 15:59:07 UTC 2015

On 6/9/15 4:01 PM, Kevin Smith wrote:
>     how about introducing a well known concept in JS as `own` ?
>     ```js
>     class Person {
>     static name String: "A person name"
>       own name String: "anonymous"
>       own items Array: []
> Let's take a step back and ask:  what's the motivation for having 
> these property declarations and initializers outside of the 
> constructor?  As Mark pointed out, it's a syntactic feature that is 
> strictly less expressive than the current solution of putting property 
> assignments in the constructor body.
> Instance property initializer syntax is really geared toward type 
> systems, where you are expressing type constraints (either structural 
> or nominal) on objects created by the given constructor.
Hmmm, this is really not the primary motivation of the proposal even if 
it does dovetail nicely with what type systems need. The proposal grew 
out of needs from real JS frameworks like React and Ember (see the 
proposal slides again for references to how these frameworks wish to use 

Instead, the purpose of initializers outside of the constructor are to 
increase expressivity in a different sense than what I think you meant 
about constructor initialization: It allows initialization that isn't 
based on logic in the constructor to be visually and clearly separate 
from logic that is. It is strictly less expressive for 
constructor-injected state patterns, but it is strictly more expressive 
for other patterns of initialization.
> I'm wary of adding syntax whose primary motivation is to express type 
> constraints, when we haven't even defined (or proposed) what typing in 
> JS means.
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list