Ideas on type hinting and named parameters

Jeff Morrison lbljeffmo at
Wed Jun 10 18:38:53 UTC 2015

On 6/10/15 1:46 PM, Mark Miller wrote:
> On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison <lbljeffmo at 
> <mailto:lbljeffmo at>> wrote:
>     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.
> So let's put a visually distinct syntax *in* the constructor. The 
> constructor is no longer as-if a function in several ways already. In 
> for a penny, in for a pound.
This might work too, but it forgoes the benefits of not having to 
override a parent constructor just to initialize child-class-specific 
Writing the initializers at the class's toplevel also seemed more 
familiar (considering cow paths in JS as well as other langs) to provide 
this syntax outside of the constructor, though.

Do you have a proposal for something that would be clearly declarative 
and clearly set the initialization apart from any logic in the constructor?
>     It is strictly less expressive for constructor-injected state
>     patterns,
> In case I was not clear, I am not for using the current 
> assignment-in-constructor to pun initializing in constructor, the way 
> Java does. Initialization and assignment should be distinct. Const 
> private instance fields must be initialized but must not be assigned to.
I have a fuzzy idea of what I think you mean, but mind clarifying with a 
code example of what you're not interested in vs what you are?
>     but it is strictly more expressive for other patterns of
>     initialization.
> What do you have in mind?
Yehuda had some examples for Ember somewhere, but one place where React 
would like this is shown here:

In this case, React is using classes as a declarative form to describe a 
component which doesn't take all of it's parameters via constructor 
injection. The constructor is handled by the base class, and it would be 
stricly boilerplate to have to write `constructor(props, context) { 
super(props, context); this.state = [...] }` each time one writes a 
child class.

Instead, the component writer describes the initial `state` property 
with a property initializer on the class and is able to avoid the class 
constructor altogether. The framework coordinates instantiation of the 
component class without having to also plumb non-framework-provided data 
through to the instantiation as well (and the child gets to avoid the 
boilerplate and potential user-error hazards of overriding the 
constructor + the ceremony of calling super(), etc).

Another simple example is one where a class defines the structure of 
some objects that should acquire some GUID property without imposing the 
need to write out a full parent constructor override:

var guidCounter = 1;
function getGuid() { return guidCounter++; }
class MyThing { id = getGuid(); }
new MyThing().id; // 1
new MyThing().id; // 2

>>     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  <mailto:es-discuss at>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at <mailto:es-discuss at>
> -- 
> Text by me above is hereby placed in the public domain
>   Cheers,
>   --MarkM

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

More information about the es-discuss mailing list