Allen Wirfs-Brock (AWB), Waldemar Horwat (WH), Brian Terlson (BT), Michael Ficarra (MF), Adam Klein (AK), Dave Herman (DH), Kent C. Dodds (KCD), Tim Disney (TD), Daniel Ehrenberg (DE), Shu-yu Guo (SYG), Michael Saboff (MLS), Sebastian Markbåge (SM), Bradley Farias (BFS), Maggie Pint (MPT), Jamund Ferguson (JXF), Myles Borins (MBS), Logan Smyth (LSH), Sarah D'Onofrio (SDO), Alan Schmitt (AS), Dean Tribble (DT), Peter Jensen (PJ), Mark S. Miller (MM), Leo Balter (LEO), Zibi Braniecki (ZB), Rafael Xavier (RX), Yehuda Katz (YK), Caridy Patiño (CP), Diego Ferreiro Val (DFV), Brendan Eich (BE), Lyza Gardner (LGR), István Sebestyén (IS)
(István Sebestyén)
IS: ECMA-404 received a negative ISO vote. Have to do another go-around and address the comment. Should do it within a month. Ball in our court.
WH: What was the negative vote?
AWB: It was a long list of objections from Japan, both editorial and larger items. Need to coordinate with Chip.
IS: ECMAScript Specification Suite fast track got an ISO number but hasn't started voting. Need eight weeks to start voting and working on translation to other official languages. Will start the ballot on April 12th. It will be a 3-month ballot. István thinks that somebody will likely make some comments, which will necessitate a second round and disposition of comments.
IS: Next Ecma General Assembly is in June. All documents are due two months in advance. We're in the RF 2-month opt-out period as of Feb 14th. Opt-out period closes on April 14th.
IS: What should we do about TC39 management structure? John hasn't been responding. AWB has been doing this temporarily.
AWB: I'm only available until May as temporary chair. Need to work out a permanent chair by then.
IS: Chairman needs to be neutral when wearing chairman hat, but can represent his company's interests when not wearing that hat. This situation comes up often in other standards committees.
AWB: Our next agenda item is a non-technical item about Code of Conduct and it might be good for István to be here.
(Leo Balter)
LEO: Last meeting got a lot of feedback; I'm trying to address all the feedback on the current CoC proposal.
LEO: The open issue is whether...
...lots of discussion..
BT: You would like us to approve this document at which point we can at least get Ecma management to take a look at it and make sure there are no problems.
LEO: We can only move to Ecma if we have consensus.
DH: I would certainly move to accept the document with the consensus that TC39 thinks it's the right document ... we'd prefer feedback than having them reject it outright.
MLS: Do we want to include just the Code of Conduct or all related documents?
BT: Are you sure we want to remove the 4th paragraph about how to report problems?
LEO: The question marks denote a place where we don't have an email.
YK: There is no consensus on having a subcommittee.
BT: We clearly need an email, we need a place to report stuff.
YK: There's no process around how the subcommittee gets formed, lots of open questions.
BT: I would like to get consensus that there should be a group of people and then we can figure out how it works.
YK: There should be at least be one person that can receive reports and do something about it.
DE: We've heard some strong arguments for separation of powers, having a separate "HR department".
DH: Have you worked with HR departments?
DT: Obviously you can escalate to István, but formally that's the primary thing for chair: moderating discussion.
MLS: It doesn't sound like we're going to be able to reach consensus on the "remedial" part of this document, but not the enforcement.
BT: Document is useless without enforcement.
AK: The message we're trying to send here would be lost without enforcement mechanism.
MPT: If everyone thinks document is toothless without enforcement, can we add some language?
AWB: I'm really uncomfortable with the whole "enforcement" idea vs. the aspirational goals of how we want to conduct ourselves. It seems to take away from the focus on how we want to behave and the focus on correct behavior.
LEO: If I rename it to Code of Conduct supporters, would that help?
MLS: Can we add the chair and the Ecma Representative for the time being?
LEO: We've had a discussion around an individual person, I'm not really...I don't think an individual person would be able to solve, for example, sexual harassment. If I'm chair, and someone brings an issue like this to me... I need support to help and/or talk to this person.
AWB: István or the chair in this case would go to the accused person and talk to them.
BT: What if the person involved is self-employed and company policy doesn't apply?
AWB: That's not most of us, but if that's the case I would hear from István.
IS: We have appropriate measures in place; we do not need enforcement here.
SDO: I would say it's not just for sexual harassment. But is there ever a reason where the chair may be non-partial in a proposal?
AWB: What should happen in that case, and in the past it has, that's the point where the chair should step away from his "chair hat" and someone else should step into the chair position.
SDO: Do we ever talk about that anywhere? It's not really something we talk about. It's maybe something we want to have written down.
AWB: This morning we talked about this. You really want the chair to be knowledgeable but for the most part detached from the tech arguments.
MM: Doesn't the same issue come up with the committee? The "sub-committee" may have strong feelings on these issues.
AK: This is one of the reasons to have multiple members of this body.
MM: Yes, but it may be an issue. All vs. 1 type of situation.
AK: There's no magic bullet here. There's 9 members on the Supreme Court, e.g. This goes to Myles' point about having a robust setup to start with so you don't have to have the process discussion at the same time you have a severe issue. Ran into this at Chromium. How do you deal with something that's happening right now? ...a bad situation to get yourself into.
MPT: There's almost no way to pre-select the Code of Conduct committee. I have many personal friends with people like Brian or ??? and because of that I couldn't participate on a committee in that situation.
MLS: But recusal, if you had a committee of four, that's easier than trying to form a committee when the violation is reported.
AWB: I don't know what the Ecma executive committee and the GA is likely to say, but I suspect that at the point where you talk about enforcement, they may step up and say "that's not our job".
WH: István said, we can do some things, but the process would have to be approved by them [Ecma]. We can't have a separate patent policy from other TCs. The process is something we need to coordinate with them.
JXF: Are we going to punt? Are there a set of things that we can approve on and move forward? If we can agree on 95%, we can move forward instead of punting.
AWB: If we have a set of documents that we're willing to pass on to the executive committee via István, total agreement isn't even needed, we can move those documents up the pipeline and get the initial feedback. There's an EC meeting in April. That's a possible next step.
IS: I think this is a good idea. You will have the first reaction by the next meeting.
LEO: I believe this current proposal without an enforcement sub-committee is not effective. If we don't set the format of how to move forward.
MPT: You will get social-media blowback if you put this out without enforcement. e.g. People on social media right now are pointing out how few women are here. Do not put that document out without an enforcement body.
AWB: I wasn't suggesting putting a document out anywhere except up to Ecma for additional feedback. We can have enforcement in it, just note that they might disagree.
MPT: Can we get consensus for István/Ecma to review? On the document as-is.
MF: Is this without defining any members of a sub-committee or an email address? How are they meant to review that?
AK: We can get that feedback... If it turns out that that's the sticking point, or if there are sticking points.
YK: I think we should move forward with the document.
BT: It would be disastrous for this group's continued existence to not let us enforce this CoC.
YK: If István comes back and says we can't enforce, that would be bad.
AWB: Let's be clear, it's not István who approves: it's the executive committee. It's "us" because it's got members of our own companies on it.
JXF: We have a CoC, which most people agree are good aspirational goals. But we're asking what enforcement looks like? Is there a minimal agreement that when there's a violation that there's a set of people get notified?
DH: It seems like we're being sloppy about what "enforcement" means to different people here. What's the meaning here? If the meaning is, literally, that there is a group of people who will meet and decide what to do...if that's a good starting point or if people think that's not enough of a starting point... I hypothesize that there is a set of people who review complaints—might be acceptable to everybody.
WH: I'm fine with that. If that's the only thing that the group reviewing complaints does under the policy. It would be more controversial if, as some suggested earlier today, that group were also tasked with creating additional more detailed discussion and participation policies than what's contained in the policy we're adopting. If that were the direction, we should figure out the policies first.
SDO: I just wanted to make a quick closing comment too. We have managed to get through this discussion without causing offense. The focus of terminology has been violators, but actually this is more about helping people feel more welcome. You know I've been terrified of this group for the last month, I'm grateful for how people have presented themselves and hope we can can continue in that spirit.
AWB: What do we need to do so we have lunch?
MLS: Are we comfortable presenting this for Ecma [executive committee] review in their meeting in April?
AWB: The Ecma executive committee.
BT: Which companies are on the executive committee? Are they TC39?
IS: Intel is there, IBM is there. Hitachi. Microsoft. Those 4 at the moment.
BT: Thanks.
IS: And of course the secretariat is there but we don't have decision power. We're just the organizer. It is basically the membership.
BT: So it seems like we do have consensus on this document as-is?
JXF: No removing that paragraph [4]?
BT: As-is, yes. OK, I move for lunch recess. Reconvene 2PM.
- TC39 will present the current Code of Conduct proposal to Ecma's executive committee.
AWB: When I said that someone should step up to being the chair, that was really addressed to the member companies. Many member companies have people that are ideally suited to running and mediating the meetings. Please check whether your company might be willing to send such a person to these meetings.
MM: There's a strong push that when assignment happens it should look like assignment. We had an Aha thought that cuts through this and other proposals: There's a whole bunch of different proposals to enhance classes. Original classes we did the minimum we could agree to, postponed other things. Proposals coming through are lots of those proposed issues. We're wrestling with them individually. Each one has its own proposed syntax, semantics. We try to pay attention to how they cross-cut. But most of these proposals have something to do with adding class members or new thing to classes.
MM: You can divide these into three orthogonal dimensions. You can characterize where they are along each dimension with a different syntactic indicator. You can do this in a way that is 100% upwards-compatible with classes already deployed (obviously a requirement). You can do it in a reasonably upwards-compatible to the spirit and the work gone into these particular proposals.
MM: Rather than combining particular, individual proposals, syntax.
MM: One dimension is placement. All proposals add some kind of member either to class constructor object or to the class constructor prototype object.
MM: Three dimensions:
- Placement:
- class constructor
- prototype
- instances of the class
- Visibility:
- public properties
- private fields
- Kind:
- method-like:
- methods (constructors, async methods, generator methods, etc)
- accessor properties?
- data property-like:
- private fields
- properties
- method-like:
MM: Private state proposal has postponed the issue of "what does a private static state look like?" All of these other things have been postponed because use cases individually weren't strong enough. By adopting an orthogonal framework, anything you don't have a well-motivated reason to prohibit, you should allow.
MM: Particulars: The placement indicator is leading keyword.
MM: The presence of a leading static keyword means "put it on the constructor object." The presence of an initial "own" keyword means "put it on the instance object." I've gotten push-back on the "own" keyword, but it needs to not be "private" or "public" since that's the kind of sematics we are trying to break up into these combinations.
MLS: Is "static own" a syntax error?
MM: Yes.
YK: Is that an orthogonality violation? (making speciic rules about "static" and "own")
YK: You don't take the Smalltalk perspective that "static" is just a meta object?
MM: No. It's too late for that in JS.
MM: So, if you just declare a method with no keyword it's already a method on the prototype.
AWB: Well we don't have a meta class......
MM: That's the sense in which I mean it's too late. For those who remember enough history, JavaScript in this regard [is more?] like Smalltalk 76 than Smalltalk 80. Smalltalk 80 had a very carefully constructed meta-braid, which JavaScript does not have. Hence "static own" doesn't make sense without that.
MM: A "protected" attribute would go on the visibility dimension, if we ever decided to do that (which I don't recommend). There's a kind of thing that's data property like..........# sign. This is also compatible with the spirit of the proposed private and public states. The difference between the proposals would primarily be the ....
MM: The beautiful thing about an initial keyword followed by name followed by initial value it looks like a declaration rater than an assignment. This gets us away from the expectation that it should have an assignment behavior.
YK: I think it still hasn't fixed the factoring issue but it has fixed the pedagogical issue.
MM: It also addresses another point of controversy: should class properties be initialized as configurable or non-configurable? I thought they should be non-configurable. But with this orthogonal pattern, it makes more sense for them to start out configurable. "own" means placement on the instance, and similar items start out configurable.
AWB: In the current class design, when we place properties, when we say "own" we are defining a property.
MM: Yes. It's private though, it's not a property so configurability is not an issue.
YK: I'm happy to accept this concession, but don't understand how you arrived at it.
YK: So "own" means "configurable?"
MM: No, own means placement on the instance. It's already placed using defined property semantics and configurable, that should apply to other places.
AWB: In the current class design when we place properties. Like when we say "own" without the private visibility we're talking about defining a property.
MM: I do mean it's specific to properties. If it's private, then it's not a property and the issue of configurability doesn't matter.
YK: But methods are also configurable. ..... I'm happy to accept this concession (which one?)
MM: It's consistent because...let's take "own" followed by method syntax or "static" followed by method syntax or simply method syntax with no "own". The only difference between the three is the keyword or its absence. The only semantic difference should be the placement.
YK: So the consisteny issue is between properties and methods. If you leave off the keyword, the property or method is configurable, it would be surprising if adding the "own" keyword made the item non-configurable.
MM: Trying to stay within spirit of orthogonality. Main value is combinatorial space of things that might get proposed. Most points don't have strong use cases. Enough would get proposed that it would create burden. We get most of the combinatorial space without burden because each element can be understood separately. We get two further benefits for the data-property-like syntax. Comma-separated list of member names with optional initializers in one declaration. And there's also thinking ahead to how this interacts with decorators and what Alan and I are proposing: if you decorate a declaration that is declaring several members, the decorator applies to each of them.
MM: There's some points in the cross-product space that are nonsensical. We can statically reject them without causing surprise, because all accepted programs follow the consistent semantics.
Oh, I'm sorry. One more detail: The constructor!
The constructor has to be specified as method-like.
YK: "Method-like syntax", can you clarify? I've read the document and I understand...I was thinking concise methods might eventually happen. We had a proposal before where you did not have to put curlies (??).
MM: I'm not only trying to rationalize proposal on the table, but also to rationalize how to further extend semantics so that they fit in the framework and keep consistency.
YK: So it looks like a method, what are the semantic consequences?
AWB: In this proposal, we have reserved the meaning of the #constructor because we might want to have something but we're not quite sure in the future.
MM: 3 reasons to prohibit something from the cross-product:
- it would be harmful
- it would be non-sensical
- we have not decided whether to allow but could decide later
YK: So what does it mean if something has method-like syntax?
AWB: A method that is a function that is defined as a property. Syntactically it's defining a function.
MM: "method-like" means it's defining a function in that you can use "super" inside the definition and it's using method syntax.
YK: Static method, it goes on the prototype—
MM: Static means it goes on the constructor.
AWB: Third dimension where methods occur. Two points, syntactic, what is the syntactic form of the thing being placed: a binding list or a concise method.
YK: What is the syntactic difference between things that are data-like—
AWB: That dimension is a syntactic dimension; whether it's a binding list or a standalone single declaration.
MM: And you can't declare an accessor method as part of a binding list.
AWB: There's actually a pull request that Mark hasn't accepted yet, the paragraph on constructors is kind of bogus. Has a whole file of examples taken from some of the existing proposals recast.
MM: Wonderful.
MM: Any objection?
BT: I have a number of points, but let's let Dan go first.
DE: My intuition is that this is one more dimension than what might be the common understanding of objects. This dimension of "own" vs. being on the prototype is definitely there, but the way that we look at classes, we don't have to think about adding the method to the prototype. With the public and private fields proposal, and the private methods straw-man, it sort of retains this property. You don't have to be explicit about the prototype vs. the instance. This is intuitive and fuzzy but seems important. Talking about "owned" vs. "notowned" gets into the weeds and will confuse people. I'm espcially concerned about non/owned methods. People might think they are supposed to put "owned" on everything, which would be hard to optimize.
MM: I understand the point. The philosophy I bring to language design is represented by goals 8 and 9: be understandable in a shallow and wide sense and invite understanding to become deeper and narrower. JS is good at that now. New people learn patterns initially but then over time they can learn the deeper semantics. The dominant use cases would be the reasonable common ones. The regularities suggest to people where they can explore deeper and find additional ways to use the system. [MM/MARKM: review and edit this]
YK: I agree completely with that philosophy.
AWB: ... Irregularities that for example are in the present proposals.
MM: The proposal uses syntax like x = 3 to declare a property on the instance.
AWB: So if you write "method"...
MM: If you write a method it's on the prototype....etc..
YK: Isn't that just the exact same consequence as with Smalltalk: "static" is already inconsistent.
MM: Static in this proposal isn't inconsistent. It doesn't have the regularity that Smalltalk has, but it has a regularity to it that's appropriate to JS.
YK: The way you get the regularity is by syntactically disallowing a field to not own .... ???
AWB: Another difference between Smalltalk and JavaScript, in JavaScript I don't think a programmer, even a journeyman programmer, can live without knowing about prototypes. That entity really is part of the language where in Smalltalk, it isn't. It's a slightly different scenario.
YK: I have an orthogonality spider sense here. ...... lots of comments about specific syntax .....
MM: What I'm saying is that's the non-orthogonality of the current proposals. With this proposal, those non-orthogonalities go away.
YK: What I'm saying is ....
MM: Distinguishing between rude surprises for authors versus rude surprises for readers. Readers do not have any of these non-orthogonalities.
YK: So if you don't see a prefix, it's means the prototype.
MM: Lots of people will ...bah humbug, lost it...
WH: How would you put a data property on a prototype in this proposal? I understand that this is a rare case and you don't want to allow it by accident if someone omits the keyword, but if you do fall into that rare case, how would you do it?
MM: You would create those imperatively, like you do now, instead of using declarative syntax.
AWB: An idea kicked around is possibility of static initializer in a class body, at class definition time. The logic of putting a real data property on the prototype is so rare...that it doesn't deserve having syntax.
DE: At a high level I like the goals about orthogonality. Aside from that big developer intuition thing, I'm not sure about adding "own methods". It seems a potential source of confusion and is redundant with property initializers. They could end up being confusing. The big use case I've heard about is people wanting bound methods, which this proposal doesn't provide.
DE: There's also an example of having an "own private" method. Maybe this would be in conjunction with lexically scoped methods in class bodies. I'm concerned if the first private method thing that we add is "own", it would catch on and be hard to optimize. Might we consider excluding that case?
MM: If we decided to prohibit those cases, that would still be consistent with this approach, it would just knock more members out of the cross-product. I would consider that to be negotiable. I also want to say that at every moment there is something concrete being proposed. Thus, the concrete proposal is that methods stay in the cross product but constructors are not included in the cross product.
AWB: An important thing about the matrix here is understanding the orthogonality. The more holes knocked into it, the harder it is to get the concept. Private methods...the utility is low but we left it in proposal to fill in matrix as much as possible. Was hoping we'd have something like lexically-scoped ...?
WH: Lexical scoped function.... could you clarify what you mean?
AWB: Since classes now have lexical scopes. There's no reason you couldn't have function declarations inside of their lexical scope.
WH: No reason, other than that the syntax is already taken.
MM: The reason I'm resisting knocking out methods is exactly what Allen says. Once you have an orthogonal framework. Once you knock it out, everything has a ....
DT: It's useful like Dan where he's mentioning these things, let's not chase down resolving particular ones. With respect to going to stage 1, these don't have to be decided now. Want to be sure we don't deep dive.
DE: I'm not sure what to do as the champion as the private state proposal if we decide go ahead with this.
DE: There was a subproblem: it could be confusing if you have a property declaration goes onto the instance and a method declaration goes on the prototype. We could solve just that subproblem without introducing this entire matrix by adding the "own" keyword. We could do that along the way to adding private methods. The thing that's good about having public/private support explicitly rather than using lexical methods is that you don't have to change call sites (e.g., by passing "this") in order to change visibility.
YK: There's a general point I want to make about if this is even an ok proposal is this an OK time for that?
Multiple: No.
MM: This proposal cross-cuts a lot of existing proposals and the whole process architecture does not accomodate that. I think that's a bug. We all know as language designers that we need to be raising cross-cutting concerns and have a way of dealing with issues that cross-cut. I'm going to leave those procedural issues to AWB.
DE: Alan has raised this before but the cross-cutting discussions have been happening the whole time among the champions of decorators and public state and private state.
MM: There's been discussion of cross-cutting concerns, but there hasn't been a proposal on the table whose effect is to have cross-cutting impact on proposals that are e.g., farther ahead of them.
AK: Let me restate from Dan's perspective. The fact that this comes as a separate proposal instead of part of what's being done from those other proposals, which seems like a change in process from what's already been happening with the other proposals.
MM: There are multiple proposals that this effects. We could merge with them, but it's more than just private, it's also the public proposal as well. Decorators, etc.
DE: I can write up a doc for the next meeting about the state that we are at for the cross-cutting considerations.
AWB: What we are asking for as this being stage 1 is really figuring out how this integrates with the other proposals. We actually considered just filing this as issues, but it would get lost at the issue level for those proposals for something that is an overriding thing. That's why we did it in this form.
BT: I think on the recent topic of process, it seems strange to me that stage 1 means we are giving consensus to change stage 3 proposals.
MM: I agree that's what stage 1 means. We could propose this as an amendment to the private state proposal, but it seemed to deserve due process.
BT: Right, I brought this up to suggest that stage 1 is not a high bar.
MLS: This would subsume private state?
AWB: This would probably combine with private state and public field proposals.
DE: I'm not sure how to proceed as the champion of the private state proposal. I think it would be reasonable to file issues within the proposals to have all of the discussion. Making it a separate proposal. How can we have multiple state proposals is a bit of a weird state to be in.
DT: It seems like it's approximately both. The idea of doing this consistent thing seems good, we should discuss. There are champions of current proposals, championing their use case. We should make things consistent across the use cases. As the consolidated thing catches up, then we can decide whether or not to merge it. We don't have to couple them so strongly.
AWB: To some degree both the public state and private state proposals were stalled at stage 2, but there were enough issues with the edge cases that they were having trouble advancing to stage 3. Take this as an offer and approach to being able to advance them all.
DE: I don't think there are that many issues. At the last meeting I laid out the issues that were open, we disagree about them, but there's a small number of issues. I would like to be able to have a discussion about which syntax we like better: the one that ?? and I are championing or this one so that we can decide and we can advance one of the syntaxes.
AK: This reminds me of the discussion of decorators and annotations. We could have had them advancing together, racing to get the "@" symbol usage. But that would have been bad. Having multiple competing proposals seems like a bad thing.
MM: When it's procedurally possible, I will propose merging the proposals.
DE: We've discussed this multiple times in the past, and had reasons to not merge the proposals.
WH: Have we resolved the cross-cutting issues with syntax?
DE: I believe we have.
WH: Does that match Mark's proposal?
DE: No.
WH: So we haven't resolved the cross-cutting syntax issues.
AWB: At the last meeting we still had intense discussions about the syntax and we didn't have consensus.
DE: But we identified all the issues...
MM: Independent of .... with a proposal for an orthogonal syntactic framework which points out all of these different cases. As long as this is viable ... this should absorb the syntactic issues from the other proposals. Then the other proposals, such as "what specifically does a private property mean...independent of placement" are semantics that can be individually worked out in the separate proposals.
DE: I'd like to hear from people who have actual feedback.
BT: If I can get to my actual points. When you sent the mail about this proposal, I became extremely excited about it. I could see how the syntax aligned with my mental model of the object model. And then I went and talked to some JS developers and universally the reaction was viscerally negative. They partly reacted to the "own" keyword. A lot of developers don't have a...
MM: Was it the "own" keyword or something else?
BT: The presence of keyword was the biggest problem. Coming from current programs where you can do data properties without a keyword, saying "add this keyword for your 99% use case" was not an easy sell. there's an arguent to be made that members today and new members tomorrow have default placement that makes sense. So allowing the implementation to place members based on the kind of member is worth more than the orthogonality. There's other issues, e.g., per instance and per class allocation semantics.
WH: You said you liked the "own" keyword but found users don't like it. But at the last meeting we had users who don't like NOT having a keyword on a definition (because it makes it look too much like assignment) so we have users on both sides of this issue. How do we reconcile them?
MF: Well there are other options like ":=". They weren't complaining about the lack of a keyword, they were complaining about the similarity to assignment.
DH: Can we forget that := was ever brought up?
DH: I have a hard time believing that the similarity to assignment is actually a source of confusion.
DH: There's an expectation about different constructs. When I think about a private data property, I expect that to be on the instance. To have to say that every time seems like it's too verbose for the common case.
BT: I would submit that we have evidence to the counter, given the significant usage in the ecosystem already.
DH: To have to say "something else" to qualify what seems like it should be the default behavior for that construct seems wrong.
??: and you would end up needing a keyword to indicate "put it on the prototype", which seems like a problem.
BT: I also want to make a broader point: I'm not saying that people I talked to represent the broader community, but it behooves us to realize that we can't really evaluate benefits of orthogonality without talking to developers and making sure they can even see that there are axes in place in the first place.
AWB: And when you talk to developers who have already been using some syntax to do this, that's a different sample than talking to developers who have not had a syntax.
SDO: From the F12 development perspective, I've had to remove the word "proto" from Intellisense when they type in window....the average JavaScript developer doesn't think this deeply. We've had to remove things because people don't know this stuff.
YK: My concern is part of the way I've been thinking about decorators. And as Dan pointed out working with people working on these other features. Decorators are a descriptive API. If you can do "@own" I'd also like "own static". There is a problem where you may be forced to type a thing that gets over-written by the decorator. In your code you may have to .... have some code to put something on the prototype.
SYG: [Asks BT what objection is about "own" keyword from developers]
BT: I think there's a perspective that I think might be true that default placement of a member should just depend on what kind of member it is. If we have a new member in the future we may have more ... trade-offs?
SYG: I guess the trade-off is, given that the default placement of, say, function bindings is confusingly global if you don't use ?? ...if we could go back and look at it, people would want it to be local. We want to, going forward, have default placement?
BT: I don't think I follow the question.
SYG: To me, I buy the argument that own vs. var or let consistency makes it easy to reason about. Two: existing programmers find that having to type "own" is onerous, so it makes default sense for these to be on the instance. Third: I think that for functions—
AK: He's saying, why do you have to have a keyword before a variable declaration?
SYG: It makes sense for me that default placement for variables is in function not global. Given that we have to live with the need to type var/let/const, it seems—
WH: Are you saying that variable declarations should look the same as assignment? They do if you omit a keyword, so what does "default placement" mean?
MM: If I may. I think Shu is saying that the cases are analogous and that declarations should have a keyword.
BT: I also happen to agree with that but no one that I talked to found that argument compelling.
BT: Since it's in an object literal context it seems weird to have to put a leading keyword.
DJR: Well, yes, it doesn't have the colon. You can make the argument that class methods or instance methods should have a keyword as a declaration point, but they don't. In this case, we just use a different initialization token. We could use a ":", an "=".
MM: Feedback from users is tremendously important. You [BT] have some and I have zero. We almost never have a scientific sample, but. The people that you asked: are they already using a syntax for members? The user feedback that I would value more is given the shape of this proposal vs. shape of other proposal and given a population of JS developers who are first learning classes in the context of these proposals: which makes it easier?
BT: I'd love to see some investigation into these questions. I want us to take a data-driven approach to which is the more easily-learned conceptual model.
MPT: I just took management of a team of 7 entry level engineers. They are actually converted network admins. Let me teach them classes next week.
MM: Please let us know ahead of the next meeting. I'd love to get the answer to that.
AWB: Which version of classes will you teach them?
MPT: I'll teach them classes as they exist today and then say: "If I had added this 'own' keyword, would that help you?"
AWB: You might try putting up two slides to show them both styles as acceptable alternatives and let them choose, that would be great.
MM: If you present them both as pure (peer?) things at the same time, that would be great.
DH: Doing user studies is good. Another form of validation I have found really illuminating. I am an outlier in that I don't always look for data-driven solution to everything...it's easy to over value how much we derive from data. There is a surprisingly illuminating exercise you can do, particularly when you'e talking about fine-grained details which you scale across your code. I'm not talking about canned example like in the slide, but I'm talking about taking some real life code and do the A/B comparison. It's particularly useful when not doing it in a confrontational setting, privately. Do you remember when I did this with comprehensions. It's just shocking how much it changed the way we thought about how these things looked. I feel very strongly that if we did a similar exercise we'd learn a lot. And it might be valuable to share that with people. This is as subject as anything to bias, but it can be very illuminating.
AWB: I want to follow up on that, we actually did that when we did the original class design. The Smalltalk class hierarchy that I implemented and reimplemented in four or five different variants, about 500 lines of code, very useful.
DH: Another quick ...... the shape of the code related to the code around it.
MM: I accept that this is a needed form of validation. Since there is a large body of Babel and TypeScript code...
SDO: What's the difference between some of the other related proposals and this one? We need to decide about that before we can judge how this would be for users...
MM: My premise in all of this work —...
SDO: Is there some way that we could have these three back-to-back and agree where the difference is and figure out the stop-gaps?
WH: This discussion is an outgrowth of the issues from the last meeting. That's what we're doing.
MM: What remote-Dan was also suggesting, now that this is on the table, that we use the issues list on all three proposals to discuss what it takes to reconcile them with each other.
SDO: Sounds like your proposal is an addendum with placement, but then we branched out to think about what customers think. How do we get back to focus about ...moving this to stage 1?
MM: There's a special focus on leading "own" because, concretely, existing proposals are incompatible with this one in this exact way. Except for that, I think that everyone would accept that this proposal is upwards-compatible.
BT: We are well beyond our timebox. I have additional points and there are raised hands. Can we have a conversation tomorrow?
MM: Would people find it acceptable today, while there are 3 people in the queue (of comments) that we take these comments and no others?
MPT: It's going to add 10 minutes.
General: Ok....
WH: Trying to figure out what the various options are. What I see as available options are:
- A. Instance property definitions don't use any keyword.
- B. Use the
ownkeyword, as in Mark's proposal. But Brian says users don't like that. There could be a couple reasons for that and I'm curious which one it is. One possibility is user dislike for any keyword. The other possibility is users not liking having to use "own" on properties but not on methods, which I can very much see how it would be annoying and confusing. This brings us to a third choice: - C. Have a keyword (example:
prop) to declare properties — all properties. Could maintain orthogonality by combining it with static if you want a static property. For properties you would need toconstorprop. These are the three possibilities I see, I haven't heard any others.
MM: Okay, well umm. So Dean...
DT: We're way over timebox. The commitee has spent a big chunk of time, it's clear the committee is very interested in this. Should this be a stage 1 thing where the committee can really look at this and begin exploring it in more detail? To me, can we go for consensus that this is something that we want to pursue and the rest of these questions become a stage 1 and stage 2 conversation.
BT: It's well-taken that the general bucket of people that haven't learned class syntax is larger than current users. But let's be clear: talking about tens of thousands or more using currently-proposed syntax. Not insignificant. If it turns out that this proposal creates viscerally negative reaction, I think we will have a problem regardless of what we're saying. I don't know how to weigh that versus the other things.
BT: I think also the story gets worse when you ask "What should TypeScript or Babel do with existing syntax?" Very hard to deprecate syntax, especially when requiring more boilerplate. You can throw warnings, etc., but that makes them more angry. You can leave the syntax in, but that breaks the mental model. You've got something without a placement sigil. I don't think that works either. Curious what you think.
MM: I would take exactly the last of the proposals. I would leave in existing syntax, make it synonymous with new syntax. Don't know enough about TypeScript environments and how well they encourage users to change things. I would provide an automatic tool that can transform them from lack of own to own. I can't force people to use the tool. The private state proposal already has a worse form of this dilemma for existing TypeScript users.
BT: You mean rationalizing private vs #? The biggest problem I have with clause16 extension is we have to explain to TypeScript users the change of the mental model. Extremely widely-used existing syntax doesn't follow this new mental model.
MM: I understand the nature of the dilemma: genuine pain point. But our responsibility in committee has to weigh the differential experience of a much larger number of future JavaScript programmers higher. If it's a big pain point for current and small gain for future: that's a hard judgment to make. More data would help.
MM: I would like to ask if there are any objections in moving to stage 1?
YK: My biggest issue with making this stage 1: we have active in-flight work. This is a potential unifying direction, but I'm worried about putting hard breaks on other proposals.
MM: I accept that we did not achieve consensus on stage 1.
YK: I do have a strong desire to see if we can make this fit with what you had in mind.
MM: We agreed that some discussions need to happen whether or not we achieved consensus on this.
- Did not achieve consensus for stage 1.
- Mark is going to reach out to the champions of the affected proposals for follow-up.
AK: Can you give a two-sentence summary of this?
AWB: TR-104 directs people to say "yes, Test262 consists of all of these things on GitHub. Go look at GitHub."
LEO: Basically a description of Test262 with formalities and ready to bring to Ecma.
AWB: Blesses Test262 as official Ecma work product. Non-normative.
LEO: There are a few facts. As of September 2016, Test262 consisted of over 23k test files...
AK: I skimmed it. I will give it affirmative: yes. I find it hard to imagine someone objecting.
AWB: I do, too, but I want to be fair. This is one of those things that Ecma as an organization: they think it's good for them.
- Consensus reached to approve and forward to Ecma GA
BT: Issues with .fill() on typed arrays. Specifically the issue involves how to do coercion on the values passed into the .fill() argument. The fix involves calling toNumber() up front.
AWB: Any other Array prototype methods not reimplemented have similar problems?
BT: I looked briefly, did not see, but didn't dig deeply.
DE: I looked. I did not find any other functions that would benefit from similar treatment.
BT: You could argue that we don't need to re-implement the algorithm.
AWB: Could this fix be applied at the Array.prototype level?
BT: No, because Array.prototype.fill doesn't do the toNumber coercion.
DE: It got re-factored after ... Shared Array buffers.
AWB: ...
BT: It's only slightly different (than arrays) but it is different.
AWB: No, but I do think you should duplicate the whole algorithm.
BT: It is duplicated.
- consensus to accept this PR
Number.toFixed()/toPrecision/toExponential
AWB: When I looked at it, it looked like it was a superfluous paragraph with those three methods. When I looked at the spec these all just looked superfluous.
BT: But this...I agree with that notion, this PR amounts to deleting those extra paragraphs that you mentioned.
AWB: It felt more like old boilerplate code, like maybe it was just some common practice to add this language.
WH: Where is this language?
BT: Look at Number.prototype.toFixed().
BT: Look at the actual PR.
WH: Ah, it's after the algorithm. It's fine to delete it.
BT: Seems fine? Good. Getting rid of it.
DE: Also, toFixed et al support greater precision from when Spidermonkey added it 18 years ago. Should we force all implementations to support greater precision?
WH: The reason we didn't mandate the greater precision and instead left it as an option back in Edition 3 was that we didn't want to require every browser to do this at the time. But if you can support greater precision like Firefox does, you should.
DE: Well we mandate ... and things that are much harder to calculate than this.
BT: I think we should consider that as part of a separate PR, Dan, if you want to whip something up along those lines?
WH: I would not want to remove the extra precision.
DE: Maybe -20 to 100 [precision]
YK: I had an issue tht was similar to this last week. I had a language binding and I had to decide about what a float in langauge A would be in language B.
AWB: I think we should take this input as input to a future proposal or PR.
- consensus to accept this PR
Presently spec implies but does not say that the compareFn must be undefined or callable. PR enforces that expectation.
BT: sort takes a compareFn. Spec does not currently say that compareFn must be callable or undefined. Implementations disagree on handling non-callable/non-undefined. Update to throw a TypeError.
AWB: Still need the language about proper behavior of a sort compareFn.
BT: ...We should really be throwing TypeError early for things that are not callable. Table [in PR] shows various testcases and existing behavior.
JSC: Could you take a look and see if you're worried about changing behavior. Most of these align with existing behavior in Chakra/Edge.
AK: There's a minor possibility of breaking something here.
AWB: It is something that non-interoperable.
AK: I did comment on the thread. I find it pretty low value here.
YK: I think some number of users will make mistakes with this.
AK: My intuition is probably that it's web compatible to change this.
MPT: This seems like a great up-for-grabs.
LEO: No tests for this. This is the most frustrating function I have for Test262, everything is implementation-defined. I'm really positive to anything that allows me to write a test on this.
MLS: The first row there [in table]: shouldn't that also throw an error...OK, so it's callable but you're not going to call it because only one element.
BT: That change was fairly recent too, not calling the compareFn if only one element.
BT: Any objections to taking this pull request?
- consensus to accept this PR
BT: All of the possibilities of how....
MM: Why did we change what we did originally to end up in this current place? Do you know whether...
AWB: I'm pretty sure from the issue thread that (tom?) is aware of it. I'm largely responsible for not doing this check before (something) because I was opposed to (computationally large checks).
BT: Yeah, and to be honest it isn't that bad and it's super confusing and anyone implementing it is asking why, why why. In the spec it's not too bad, but in engines it's a lot more (obviously unecessary)
MM: I'm completely satisfied.
WH: Is it possible that the proxy checks involve more proxies?
AWB: Well yeah, sure, if they access an object using any of the meta operations and if it does it will invoke the handler.
MM: This is not even an edge case, a major part of proxy design...it's by the double lifting trick that you can implement the policies that are .... of the track in one place.
BT: Any objections to taking this PR?
LEO: If we accept this we will have breaking tests.
BT: We have a needs-tests label. Feel free to apply it.
BT: I updated permissions to ECMA-262 so that delegates have ability to add labels to ECMA-262 issues and to close issues and pull requests and to push branches, which I think will be helpful in the next year.
AK: Need to be clear about what kind of comparison is used when things are added.
WH: This is a one-line change?
BT: Roughly I think so yeah, you could expand that one line into a loop with explicit? checks.
AK: Every other use of the word "duplicate" in the spec is...not these reified objects...
BT: But there's only one way to compare a string right?
AWB: ... symbols?
AK: As the editor, keep an eye on that. I fear that someone will use "duplicate" somewhere and not know what it means.
- consensus to accept this PR
BT: Current spec won't throw when toIndex causes buffer to be detached.
- Add another isDetached array buffer check.
- I think moving the toIndex further up is the correct way here.
AWB: Does moving it up change the order in which arguments are examined?
BT: It does not change the observable order of side effects. It should be fine to do and not cause compat problems.
- consensus to accept this PR
BT: Currently spec says substitution strings ($1, $2) with indexes beyond the matches groups (i.e. $5, $6, $7) is implementation-defined.
BT: All implementations agree that the replacement is not done for such substitution strings. PR aligns with implementations.
AWB: In my work on this in ES5 and ES6, for things like this I tried to propagate what had been specified in...?
WH: When we wrote this in Edition 3, the plan was to only allow these things when there was actually a capture of that number. Unfortunately on some implementations, if there were only 3 captures and you did $4, you'd get a literal $4 in the result instead of a replacement. We wanted to deprecate that.
BT: So you wanted empty string?
WH: No, we wanted an error.
AWB: So is there any chance that throwing an error for this would be web compatible. The hope to deprecate this has failed.
BT: That is excellent context and it makes me a little sad about removing this.
YK: I think there is a useful discussion we should have about deprecation.
BT: I will add notes with history that Waldemar provided.
MPT: Did you want to do the needs consensus on ??
BT: I'm open to continuing.
- consensus to accept this PR