why not "new" instead of "constructor"?
[snip]
let Point = class { x: 0, //not really needed unless defining an object exemplar y: 0, new(x,y) { this.x = x; this.y=y; } };
Yes this is better, could we go one step further and allow for
Point.new(1,2)
to work instead of new Point(1,2).
If we just make the "new" method property create an instance of Point and pass that in as the this value then it would solve the need for having new <ObjectExemplar>.
This would behave similarly to selfish's .new function.
The only issue is that all code that checks obj.constructor for the link will break because we no longer link the constructor anymore.
Why can't we just use "new" in such declarations:
let Point = class { x: 0, //not really needed unless defining an object exemplar y: 0, new(x,y) { this.x = x; this.y=y; } };
It is shorter to type, reads better, and is much more suggestive of its direct relationship with the new operator.
The only real issue I can think of is that in ES5 unquoted "new" is a valid property name in an object literal. However, in this case we are using it in a new syntactic context (a concise method property) that doesn't exist in ES5. Whether or not we also let gave new this meaning in a propertyAssignment form (a breaking change) can be a secondary design decision to be considered. Related would be concern that there are frameworks that actually use obj.new() as an idiom. We probably would need to be careful to not break those, but I think that is also doable.
There are various semantic details that need to be specified, but none of them seem difficult. Before getting into them, I'm more interested in what is essentially a bikesheding questions: is this a direction that we shoud consider?
I like the idea of replacing the method name “constructor” with something better, but “new” suggests instantiation and initialization to me. Is “init” a possibility?
On Nov 19, 2011, at 9:42 AM, Jake Verbaten wrote:
[snip]
let Point = class { x: 0, //not really needed unless defining an object exemplar y: 0, new(x,y) { this.x = x; this.y=y; } };
Yes this is better, could we go one step further and allow for
Point.new(1,2)
to work instead of new Point(1,2).
If we just make the "new" method property create an instance of Point and pass that in as the this value then it would solve the need for having new <ObjectExemplar>.
This would behave similarly to selfish's .new function.
You are pushing into spaces I want to avoid discussing right now because we have a tendency to prematurely "rat hole" on such secondary issues without resolving the primary question.
For now, the question is: is "new" a more desirable name than "constructor" for the programmer provided code that is run by the new operator?
The only issue is that all code that checks obj.constructor for the link will break because we no longer link the constructor anymore.
This falls into the area of "semantic details" that I alluded to. If a yes consensus formed for the above question then it would be worthwhile to start to dig into those details as we tried to move on to the next question: Is is practical to use "new" as the name ...
On Nov 19, 2011, at 9:54 AM, Axel Rauschmayer wrote:
I like the idea of replacing the method name “constructor” with something better, but “new” suggests instantiation and initialization to me. Is “init” a possibility?
Is that distinction between instantiation and initialization very important for the average JS programmer (or stated another way, is the average JS programmer at risk if they fail to understand that distinction). Is the sophisticated JS programmer who understand the difference between instantiation and initialization and the detailed semantics of the new operator going to get confused it the initialization code is labeled with "new"?
My intuition in both cases is that the answer is no. If I'm correct then "new" seems like the better alternative.
You are pushing into spaces I want to avoid discussing right now because
we have a tendency to prematurely "rat hole" on such secondary issues without resolving the primary question.
I do have a bad habit of doing that!
Is that distinction between instantiation and initialization very
important for the average JS programmer (or stated another way, is the average JS programmer at risk if they fail to understand that distinction). Is the sophisticated JS programmer who understand the difference between instantiation and initialization and the detailed semantics of the new operator going to get confused it the initialization code is labeled with "new"?
I was going to suggest "init" myself, but given those arguments I'd actually agree that "new" is preferable for the average programmer.
True. A method automatically does the right thing where it matters, anyway.
It’s nice to see the two concerns instantiation and initialization separated with the new() method. IIRC, the problem with subclassing Date is that it doesn’t separate them(?) If I’m right, an init() method would solve the problem. If not, can I read up on what the problem is?
Thanks!
Axel
Allen,
Yes, this makes sense and is desirable. ( the rationale being that the word "new" in "new Point" can be connected to "what is going to happen" when the code in "new(){ ... }" is executed )
On Nov 19, 2011, at 9:34 AM, Allen Wirfs-Brock wrote:
<meta>In the following I'm going to use syntax from by class operator strawman: strawman:class_operator However, the basic idea should be applicable to several of the class declarations proposal that are drifting about.
BTW, I'm pretty sure that this isn't the first time the idea has been suggested.
By Bob Nystrom among others early this year.
Most recently here: strawman:minimal_classes
Turns out anything we do here is a special form, at least for named classes. So 'constructor' in the harmony:classes proposal still on the wiki (which is not fully in Harmony)is not just a prototype method like any other. Therefore I agree we could use 'new' instead.
On Nov 19, 2011, at 9:54 AM, Axel Rauschmayer wrote:
I like the idea of replacing the method name “constructor” with something better, but “new” suggests instantiation and initialization to me. Is “init” a possibility?
Who said anything about "replacing"?
If we are trying to match or sugar the prototypal pattern, then whatever the constructor name or keyword in the syntax, there must be for class C a back-link C.prototype.constructor.
I like the idea of replacing the method name “constructor” with something better, but “new” suggests instantiation and initialization to me. Is “init” a possibility?
Who said anything about "replacing"?
If we are trying to match or sugar the prototypal pattern, then whatever the constructor name or keyword in the syntax, there must be for class C a back-link C.prototype.constructor.
I only meant replacing in as far as the method that was previously called “constructor” is now called “new” in Allen’s example:
let Point = class { x: 0, //not really needed unless defining an object exemplar y: 0, new(x,y) { this.x = x; this.y=y; } };
On Nov 19, 2011, at 2:58 PM, Axel Rauschmayer wrote:
I like the idea of replacing the method name “constructor” with something better, but “new” suggests instantiation and initialization to me. Is “init” a possibility?
Who said anything about "replacing"?
If we are trying to match or sugar the prototypal pattern, then whatever the constructor name or keyword in the syntax, there must be for class C a back-link C.prototype.constructor.
I only meant replacing in as far as the method that was previously called “constructor” is now called “new” in Allen’s example:
let Point = class { x: 0, //not really needed unless defining an object exemplar y: 0, new(x,y) { this.x = x; this.y=y; } };
That's the point: it's not just a method. It is a special form. In classes as proposed where the name was 'constructor', or if it's 'new' as in Dave's strawman:minimal_classes proposal. It is not just another method that happens to have a catchy name.
On Nov 19, 2011, at 3:14 PM, Brendan Eich wrote:
That's the point: it's not just a method. It is a special form. In classes as proposed where the name was 'constructor', or if it's 'new' as in Dave's strawman:minimal_classes proposal. It is not just another method that happens to have a catchy name.
See the desugaring in Dave's proposal for why, and consider how 'constructor' doesn't matter. We could call it 'snoopy' and there would still be special-ness to the form, extra semantics that any old method of a name other than the one we pick for the constructor would not have.
Turns out anything we do here is a special form, at least for named classes. So 'constructor' in the harmony:classes proposal still on the wiki (which is not fully in Harmony)is not just a prototype method like any other. Therefore I agree we could use 'new' instead.
That’s what I missed. But wouldn’t that change Allen’s class operator to something that performs David’s desugaring as a tranformation (from something that simply returns the value of property constructor)?
On Nov 19, 2011, at 3:54 PM, Axel Rauschmayer wrote:
Turns out anything we do here is a special form, at least for named classes. So 'constructor' in the harmony:classes proposal still on the wiki (which is not fully in Harmony)is not just a prototype method like any other. Therefore I agree we could use 'new' instead.
That’s what I missed. But wouldn’t that change Allen’s
classoperator to something that performs David’s desugaring as a tranformation (from something that simply returns the value of propertyconstructor)?
I'm not sure. The two proposals are independent so far. Harmonizing them could be helpful.
<meta>In the following I'm going to use syntax from by class operator strawman: strawman:class_operator However, the basic idea should be applicable to several of the class declarations proposal that are drifting about.
BTW, I'm pretty sure that this isn't the first time the idea has been suggested. We've had lots of class proposals go by with lots of moving parts. Some of those parts may be useful even if the whole proposals didn't stick. </meta>
The current thinking is that a class exemplar is defined as
let Point = class { x: 0, //not really needed unless defining an object exemplar y: 0, constructor(x,y) { this.x = x; this.y=y; } }
and instantiated as new Point(1,2); //call the constructor method from the class exemplar
There is semantics included in the class operator proposal and other class proposals to cover what happens with the constructor isn't explicitly defined.
However, another issue is that "constructor" is an ugly and idiomatic name.
Why can't we just use "new" in such declarations:
let Point = class { x: 0, //not really needed unless defining an object exemplar y: 0, new(x,y) { this.x = x; this.y=y; } };
It is shorter to type, reads better, and is much more suggestive of its direct relationship with the new operator.
The only real issue I can think of is that in ES5 unquoted "new" is a valid property name in an object literal. However, in this case we are using it in a new syntactic context (a concise method property) that doesn't exist in ES5. Whether or not we also let gave new this meaning in a propertyAssignment form (a breaking change) can be a secondary design decision to be considered. Related would be concern that there are frameworks that actually use obj.new() as an idiom. We probably would need to be careful to not break those, but I think that is also doable.
There are various semantic details that need to be specified, but none of them seem difficult. Before getting into them, I'm more interested in what is essentially a bikesheding questions: is this a direction that we shoud consider?
<meta>In the following I'm going to use syntax from by class operator strawman: http://wiki.ecmascript.org/doku.php?id=strawman:class_operator However, the basic idea should be applicable to several of the class declarations proposal that are drifting about. BTW, I'm pretty sure that this isn't the first time the idea has been suggested. We've had lots of class proposals go by with lots of moving parts. Some of those parts may be useful even if the whole proposals didn't stick. </meta> The current thinking is that a class exemplar is defined as let Point = class { x: 0, //not really needed unless defining an object exemplar y: 0, constructor(x,y) { this.x = x; this.y=y; } } and instantiated as new Point(1,2); //call the constructor method from the class exemplar There is semantics included in the class operator proposal and other class proposals to cover what happens with the constructor isn't explicitly defined. However, another issue is that "constructor" is an ugly and idiomatic name. Why can't we just use "new" in such declarations: let Point = class { x: 0, //not really needed unless defining an object exemplar y: 0, new(x,y) { this.x = x; this.y=y; } }; It is shorter to type, reads better, and is much more suggestive of its direct relationship with the new operator. The only real issue I can think of is that in ES5 unquoted "new" is a valid property name in an object literal. However, in this case we are using it in a new syntactic context (a concise method property) that doesn't exist in ES5. Whether or not we also let gave new this meaning in a propertyAssignment form (a breaking change) can be a secondary design decision to be considered. Related would be concern that there are frameworks that actually use obj.new() as an idiom. We probably would need to be careful to not break those, but I think that is also doable. There are various semantic details that need to be specified, but none of them seem difficult. Before getting into them, I'm more interested in what is essentially a bikesheding questions: is this a direction that we shoud consider? allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111119/c85f936c/attachment-0001.html>