On 6/10/15 1:46 PM, Mark Miller wrote:
On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison <[email protected]
<mailto:[email protected]>> 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
properties.
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:
http://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html#es7-property-initializers
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
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
