Allen Wirfs-Brock (AWB), Waldemar Horwat (WH), Brian Terlson (BT), Michael Ficarra (MF), Adam Klein (AK), Chip Morningstar (CM), Dave Herman (DH), Kent C. Dodds (KCD), Kevin Gibbons (KG), Tim Disney (TD), Daniel Ehrenberg (DE), Shu-yu Guo (SYG), Jeff Morrison (JM), James Snell (JSL), Keith Miller (KM), Myles Borins (MBS), Rick Waldron (RW), Mariko Kosaka (MKA), Stephen Murphy (SMY), Rob Palmer (RPR), Andrew Paprocki (API), Philippa Gardner (PGR), Sam Goto (SGO), Mark S. Miller (MM), Nathan Hammond (NHD), Masud Rahman (MRN), Henry Zhu (HZU), Sebastian Markbåge (SM), Joe Mordetsky (JMY), Franziska Hinkelmann (FHN), Caridy Patiño (CP), Myles Borins (MBS), Ron Buckton (RBN), Ashley Williams (AWS), Domenic Denicola (DD), Patrick Soquet (PST), Peter Hoddie (PHE), Leo Balter (LBR), Ben Newman (BN), Jafar Husain (JH), Yehuda Katz (YK), Sarah D'Onofrio (SDO), Kirill Cherkoshin (KCN), Andres Suarez (ASZ), Diego Ferreiro Val (DFV), Tzvetan Mikov (TMV), Brendan Eich (BE), István Sebestyén (IS)
(unanimous consensus)
IS: The minutes have two parts. One part is the "list of metadata" about the meeting. The second part is the technical notes.
IS: First time somebody asked for the complete minutes of those meetings. Intended to inform the people who are not involved in TC39 what is happening in TC39.
IS: There were questions around the process of the opt out for the latest ECMASCript standards.
IS: This is interesting as I always thought that for programming languages (and not e.g. about their compilers) it is hard to get patents therefore a "royalty-free opt out" that would be something that is new for this committee.
IS: As expected, we have received no comments during the opt-out period that we have started on February 14 and ended on April 14, and therefore we have approved the specification from the TC39 point of view. You may remember that at the March meeting the TC39 approval of ECMA-262 and ECMA-402 new editions were conditional based on the positive outcome of the "opt-out" for both standards.
IS: The standards have published internally on the Ecma internal website, and as ususal the New standard version will be available for public download immediately after Ecma GA approval, latest on June 28th. Congratulations on the excellent work you have done.
IS: Just to remind. Anybody can add them via the reflector, at any time. We agreed to this a few meetings ago, in order not to steal time from the meetings
IS: Allens remark about 20 years of ECMAScript approval in Ecma is well-taken. This is always a good opportunity for PR. You may wish to organize some conference/press conference given the opportunities presented by the size of the community. (Presented as an idea.)
IS: Would like to bring attention to the work that this committee is doing, and the community built around the language and specification.
IS: Don't have a chairman for TC39 and are looking for a replacement. AWB has been acting chair.
IS: Chairman is often involved in other technical committees.
IS: Roles are distributed across membership.
IS: Ordinary members have first priority to take leadership roles, if they wanted to. So far they haven't expressed interest in taking a leadership role in TC39.
IS: Therefore now other members of Ecma (better TC39) may step forward and volunteer themselves, including non-profit members. Anybody who is an Ecma member in good standing can offer themselves.
IS: However, to lead such a big and intensive group like TC39 is a challanging job. So experience is required. Direct recruitment of people is the next step - if we can not find a good leadership among ourselves, I recommended Rex Jaeschke as an excellent candidate for that (details about Rex has publishedon Github), but this decision is entirely up to the committee (see https://github.com/tc39/Reflector/issues/71 )
IS: Rex has been working with Ecma for 10+ years and is very experienced with standards committee work. Knows Ecma very well and has been working with several technical committees already. Very familiar with programming languages in general. Participating in TC49 (C#). Main position that he has held is that he has been chairing JTC1 SC22 (including C++). This is the place where we are fast-tracking also the TC39 standards. He was there recently when we discussed with ISO the fast-track of ECMA-414.
IS: ISO allows you only to be a chairman for 9 years. He has been the chairman of SC22 for 8 years, therefore he has availability forthcoming. He knows a lot of people on this committee very well and has worked with people in this committee previously.
IS: He also offered to provide some background information on himself, available on the Reflector.
IS: Could invite him informally to the July meeting for continuing relationship development.
IS: Re-emphasizes that this proposal is at the discretion of the committee.
IS: Size of TC39 is growing, therefore we need to do more planning in advance of the meetings.
IS: When we get > 50 people we will need to deal with hosting and organizing meetings in an different way
IS: No consensus around different models of working with subgroups or a combined plenary session.
DE: Leo expressed interest in being chairman?
LBR: Searching for somebody who would not be taking sides as a person who would act as a chair. Believe that it is good to have a conversation with Rex and let TC39 consider that as an option. I volunteered myself for something I don't have a lot of experience with. Rex has a lot of experience which we could use to be able to learn from. I would love be part of a vice chair group (although not official by ECMA)
LBR: There may be additional people who have interest.
DD: What exactly is the role of a vice-chair, and a "vice-chair group"?
YK: Single person who has the sole responsibility for setting the direction of the conversation. Better received if there is a working group.
LBR: The vision that I have is: Support the chair in all of their functions. There are a lot of things during the meeting. Supporting the hosts in the process of setting up the meetings. Supporting the process of followup after the meetings, sending the notes... Having a group of people to support these goals is valuable.
DD: Confirming: Vice chairs would not be setting direction of conversation in the meeting? But would instead be helping with administrative efforts?
LBR: Confirm.
AWB: There is a lot of stuff that a chair does that committee does not know: Primary layer between committee and ECMA. Months and months dealing with patents, documentation... Takes real time to interact with ECMA. Also helping the committee structure and organize technical work.
AWB: This also works to develop future leadership of the committee. A vice-chair could step forward to run a meeting in the event that the chairman is unable to be present.
IS: Its is very much how you define it. How we organize it is depends on Chairman, its very free.
DD: What I found clarifying that . The primary thing that person will own is not just the operating of the meeting, but there is also additional unseen work. The conversation that we need to have in this room is focused on determining the flow of meetings.
DE: I can help with the administrative stuff, but too involved technically. It would be desirable that the person running the meeting has a internal understanding and technical expertise to weight on the decision in an unbiased way.
LBR: I am tempted to not sign up for too much ("overloaded") and I want to be able to take sides. I am open to try and experience with Rex here.
LBR: To follow our vision goals, we should the use language Chairperson or just Chair instead of Chairman.
AWB: We will call it Chair going forward. Rex can be very helpful trying to figure out the structure. The recommendation is to try to get Rex to do this, but waiting until is here to come up to speed so he can help with advice and the administrative stuff. Give him a chance to show his expertise.
WH: Rex should be involved in this discussion, bidirectionally so those of us who don't know him get to meet him as well.
AK: We should all have an opportunity to have a conversation with Rex.
WH: How would the finances work?
IS: We would have to pay to bring him in as a consultant for the first little bit. Ecma has to champion finding a chair in the event that it is not handled internally.
Discussion about ECMA finances
LBR: Is there any alternative?
WH: Let's not worry about that for now.
AK: Would be happy to have Rex come have the conversation.
SDO: SHould specify what the roles are more concretely so that we know who these people are.
AWB: None of us are here because we want to be bureaucrats.
AK: Vice-chair is an important for growing skills. (assent from LB, AWB)
DE: Who is going to run the next meeting?
AWB: I could chair one last meeting, but come away with a new chair at that meeting.
DD: Doesn't like the idea of temporary chair?
FHN: Having an acting chair of Leo next meeting, with AWB as backup?
YK: Expressing concerns about Rex is being presented as a top-tier candidate with no familiarity to the members of the group.
BT: Had concerns, but everything I've had in terms of interactions or questions about working with Rex was very positive. He seems like a very good candidate. Likes non-paged standards, which BT loves. Seems to wish to evolve the standards process itself. Standards resume is something like 30 groups deep. Would be valuable to have somebody with that degree of expertise.
YK: My only concern is that the details in how we work in this committee requires a lot of history and past knowledge.
MM: We should make sure that he is enough informed to make sure that it is something that he is interested in.
BT: Has the necessary qualifications, but we can't make a decision sight-unseen, and he can't make the same about us.
Invite Rex to the next meeting.
General assent to Leo running the next meeting.
LBR: I'm willing to try.
AWB: I may not show, it would be valuable to have it, but he'll play it by ear.
LBR: Will need to define and document the role.
https://github.com/tc39/code-of-conduct-proposal/issues/25
(István)
IS: Executive committee's reaction to the proposal was immediately positive and received broad support.
IS: Should this be all of Ecma or just TC39? Decision was to test it on TC39 and then possibly consider expansion to all of Ecma based upon the experience that we have here.
IS: Ecma General Assembly may eventually take it over as an Ecma-wide process (in the long run...).
IS: Ecma wanted to participate in the discussion about the final text. Have produced a new version and fed that in as comments here: https://github.com/tc39/code-of-conduct-proposal/issues/25.
IS: Somehow this policy should be linked into the Ecma policies. Allowed to introduce these things as riders via the Ecma bylaws (possibly paragraph five?)
IS: Some of the execution points that you have created were too detailed in terms of management function which conflicts with the style of the Ecma bylaws and policies. Intentionally simple so that we don't have to micromanage the groups. Give more flexibility to the implementers.
IS: The changes the General Assembly has made, is linked in the current proposal. Is up to the committee to review them and start a conversation if there are disagreements. If agreement is meet before the July meeting it can be approved by TC39 in the JUly meeting and publish and implements it.
IS: By the way, for formal TC39 approval we need to publish the final version 15 days before the TC39 meeting. And this can become after approval the "experimental code of conduct policy for TC39".
BT: I really appreciate Isabelle Harper's help getting this through the executive committee.
WH: We can't do this without blessing of the executive committee. They are the ones responsible for modifying ECMA's rules.
YK: Physical danger has been removed which is odd, and should be revisited. By definition, CoCs are trying to provide more protections than the protections of law enforcement.
LBR: Code of conduct doesn't prevent anybody to seek for legal authority.
IS: Need to build consensus between us and the executive committee.
IS: Shouldn't have one-sided discussion
Need to ensure that we have a consensus on this side prior to the conversation with Isabelle.
AWS: Need to have consensus to progress the conversation further
MBS: Would it make sense to have an open group internally with internal stakeholders as a representative of this groups.
BT: We should do it weekly until we have a document ready. Coordinate it via the reflector.
Documents TC39-2017-016, TC39-2017-017 (pdfs of documents available in Reflector repository).
AWB: Questions on the fast track of ECMA-404 (JSON specification).
AWB: Seeking consent that we don't want to review everything that comes out of Ecma 404.
AWB: Japan editor has asked for some changes (mostly editorial) that the committee has to revise before final approval.
MM: Retitling from "format" to "syntax". Historically we have had a lot of trouble explaining what JSON is not, i.e., that it is just a syntax with no standard meaning. Changing the title to "syntax" should help reduce such misunderstandings.
AWB: Changes are for clarifications and make things more explicit.
AWB: Has no objections to approving it sight unseen if we have consensus.
YK: No particular concern if there aren't user-facing changes. Happy to delegate to people who care.
(Brian Terlson)
Why are restricting on two tokens?
YK: Would prohibit creating an async method called "function"?
BT: Correct
AWB: Unless quoted, this is allowed.
YK: increasingly its ok to use keywords, and this is an inconsistency.
MM: is two token lookahead concretely a problem for implementors?
KG: Seems ok since its already very complicated.
KM: non-issue
WH: Can get us unintentionally stuck in a corner, where we can't extend language in the future
MM: Acknowledging Waldemar , in the sense of implementation concern, YK points is valid: We should be careful with the inconsistencies for keywords.
DE: Can I withdraw this patch?
BT: If we don't get consensus for it, or against it, it will sit forever.
WH: I have not have time to consider the implications of this.
MM: Implementors should take a look and raise concerns when needed.
WH: (a few minutes later) Having looked at the implications of this in more detail, I'm fine with rejecting the issue with no action.
BT: Chackra teams agree with the conclusions for changing the behaviour for regexp.
DE: Andre specified several previously missing "\c" cases
YK: Whats the problem with the characters? Why Annex B?
DE: All the surrounding parts are Annex B
AWB: No way a define property could be use to exactly define a module export in the namespace object.
DH: why diverge on cases that match module invariants? no.
DD: Any objection?
DH: verify not the case that you can observably change an exported NaN via DefineOwnProperty (from the outside)
DD: You can see the mutations from outside.
AK: Spec doesn't let you change
DH: Just verifying.
YK: Writeable property that you can't write to? Seems weird.
MM: if thing you're exporting is const, does the property descriptor "non writable"?
AK: No, all descriptors marked as writable
DH: Without knowing the details we should not think that ES5 refection mechanism can describe all aspects we encounter.
AK: Shouldn't be able to tell how someone declared a binding in their module
MM: should be able to communicate that a value is stable. this is the descriptor "contract" guarantee
Is the module namespace object non-extensible?
Yes.
YK: There is a a new property that we define as writable that is not writable.
AWB: Not new.
AK: Since... Proxys!
YK: If you define object.define property with writable true, and you can't write on it...??
MM: Non-writeable provides guarantee. Writable provides no guarantee.
LBR: We need to provide tests before merging. Okay to mark as consensus.
BT/WH/DE:
Discussion re: precision for toFixed and others
BT: Why do the higher limit?
WH: This lets you print exact values of doubles. I implemented this in SpiderMonkey and have found it very useful to educate people on how doubles work.
?: The negative limit makes no sense
DD: It's well-defined.
WH: Yes. It rounds to multiples of positive powers of 10 instead of negative powers of 10. It's only sensible for toFixed, which is why toExponential doesn't support it. But I'm fine with negative numbers going away.
DE:
BT: We presently support 0 to 21. This is just changing the requirements to the range 0 - 100.
DE: Yes
YK: What do admins do if you put a number outside of the range? (after the patch)
RW: RangeError
BT: Can also change it to not throw for negative to
KM: The error is also thrown by typed arrays.
MM: We should be consistent across all of the occasions to not throw, or this is fine.
(Mark S. Miller, by Claude Pache)
MM: WH & DE objected to exempting subclasses from legacy features
DE, WH: Exempting subclasses doesn't serve positive purpose and is very confusing.
MM: Withdrawing restriction exemption for subclasses, keeping restriction exemption for realms
AWS: How is it identified by realm?
DD: New slot for realm, specifically for regexp
AWS: Legacy properties are on subclass constructor?
MM: No, they're only on the RegExp constructor.
MM: Explains how prohibition across realms works
WH: Another issue: for polyfilling, want to run regexp without polluting static properties. Possible future flag added to regexp to suppress legacy feature. In jest, I suggested "s" flag.
(Domenic Denicola)
DD: Ready for stage 2; let me give an overview of the spec:
import.meta is a "meta property"AWB: why not a map?
KG: Always use maps
DH: using a map will be too unergonomic
DD: using a map makes calling methods terrible
DD: Bradley Farias noted that using a null proto object discourages code from modifying the object prototype of module object
AK: Nice for consistency with namespace objects
AWB: ns objects are special case
Discussing polyfill story
BN: In node there is a Module constructor with a prototype, which is shared by all the module objects. In practice, it's a convenient place to put shared operations. import.meta could have a common prototype? Or not, and the host environment could choose to call Object.setPrototypeOf(...)?
YK: No longer worried about not sealing the objects because they're not shared.
MM: this object is the "system object". When discussions arise about what goes on the system object, this will be the place to put them.
DD: No, because this object is for hosts only.
MM: I just don't want Domenic to be blind sided
(Jeff Morrison)
JM: integrating public and private into one proposal to avoid proposals racing
JM: Address orthogonal class proposal
(working through Orthogonal Class Conventions slide)
CP: q about "own" keyword
JM: without keyword indicates prototype, with keyword indicates non-prototype
(discussion re [[Set]] vs [[Define]])
YK: Ok with [[Define]] as long was we work on mitigations
(Working through rules and solution for future additions)
Create new keyword for "proto" members, require this keyword for any future proto fields proposal and make it optional for methods.
Include 2 categories in the framework design: "fields" and "methods". Within each category, say that the common-case form uses the no-keyword syntax, all ... (slide changed)
JM: want to choose one of the above this meeting to fix the orthogonality issue before we can proceed.
WH: In favor of 2
WH: What is the syntax for const fields?
JM: const fields, depending on what the mean...
WH: For the sake of discussion, let's say that they are initialized once, can be own or static
JM: would not be one of these mutually exclusive categories
RBN: no issue in TS, use "readonly" with accessibility modifier
KG: No own or proto keyword
RBN: No
JM: modifiers in languages that allow varying order are problematic, can be addressed with grammar
WH: In C++ you can write static const but not const static.
JM: concern that own keyword, interaction with decorator:
class C {
@deprecated own foo = 42;
}
@deprecated may choose to not to store foo as an own propertyown field, but the decorator will violate that intention.JM: The issue is the case where an own property gets turned into a getter/setter
JM: Possible solution:
WH: (question about interaction with the two framework solutions shown earlier)
RW: Need to review those two options in the context of this solution
JM: applies in either case (still needs to work out specifics with YK, re: decorators)
YK: normal usage of property doesn't change: x.y is still the same whether own property or getter/setter, changing to static makes a difference
DH: evidence that we need a keyword for instance properties is weak, considering TS ships without keyword. A growing decision tree, accumulating
WH: need to address decisions in order
JM: hoping to find objective ways to find a solution, vs subjective "good" or "bad" discussion
DH: (some objection to the design process that I didn't fully catch before the next person spoke)
AK: We've been debating syntax for a very long time, he's offering ways to objectively work through design decision tree
DH: There was a slide that indicated some additional syntax for an uncommon case
(I'm way behind)
DH: problems in the reasoning that lead to the own keyword in the first place
JM: Two possible conclusions:
DH: The own keywords is a trcit subset of option1 and option2. THey both map variants of proposal that dont "own" or "proto"
DD: feedback on having keyword?
JM: Typescript or Babel don't have keywords, thats all we know from the outside.
DD: when original unified proposal, community pushed back against required keywords
AWB: people who are not used to keywords, don't like keywords
JM: That is a tricky debate point, because people can be upset either way (for using it already or no have used it yet)
YK: Significant reaction for foo = 1 vs. own foo =1, reaction is often at "public", not specifically "own"
DD/RW: agree
MM: own vs. shared is a very intuitive contract...
AK: not shared
JM: say we used proto in front of
??: If you had an alias for own and shared will be easier to understand
AWS: I believe if the keyword was shared, it would be more likely understood
AWS: instead of focusing on how the language works from implementation details, focus on how it can be more easily understood/intuited
BT: Do you think own has similar problem, that begs the question what is it? what is for?
AWS: to introduce a not feature that doesn't map to another language, especially in a way that's not clear
MM: This argues against own
AWS: yes
MM: Also argue that declaration looking like an assignment is confusing?
AWS: Yes
DD: Yes
MM: Given those points, does it lead you to 1 or 2?
AWS: not sure of all the implications
JM: mentioned that assignment confusing and most people don't get difference between assignment and definition
AWS: (restating)
MM: Given those intuitions...
RBN: We also have assignments in function parameters (as another precedents)
AWS: Don't think people will think own as similar to let, const, var
DD: Looks more like static
MM: They'd learn
AK: There is evidence that says users have been working with "no keyword" and learned
D: What is the path for people to go from 0 to learn the language in a comfortable way. A keyword will bring one set of confusions. With assignment, people might not have clear the semantics. ^-- Who is this?
AWS: Adding own looks weird to learn, since there is not precedents to it.
AWS: Looks like assignment no matter what, confusion no matter what.
MM: So, additionally adding a keyword is more confusing?
AWS: Yes
AWB: "own" is already used in the language in getOwnProperty... methods
AK: Extends has the same context
AWS: Most people don't realize it exists.
YK: "own" is not the same thing as let, const. In some sense are declarative, but people experience it as assigment only, introducing own with that semantics can be confusing.
AWS: An assignment with a semicolon will be treated as in order (like statement list)
There is confusion that this looks like a statement list, own doesn't mitigate this
JM: The committee has to make a decision. New syntax might confuse somebody, but we need to walk that fine line.
MM: The case for own that we made, with the case stated, we are willing to give up "own".
JM: We have consensus for solution 2? We are agreeing to the syntactic specification that Dan has put together in thel ink proposal in teh agenda. which is a merge of a private fields and public fields proposal
Moving on to DE's https://littledan.github.io/proposal-class-fields/ https://tc39.github.io/proposal-class-fields/
WH: The proposed spec does not have an own keyword, but does not preclude supporting own to designate instance methods
DD: There are two small changes: Supporting private static fields: It feel very natural since the semantics are consistent. Also comma separated fields declaration for static and non-static.
WH: is there a no line break restriction on static?
KG: Methods already do not have that restriction, so can't really introduce it
DE: Kevin implemented this and it works
WH: own (or most other keywords) does not have any meaning (right now). If you add it later, it will need to have a line break restriction to avoid changing the meaning of
```own
foo() {...}```
which currently would declare a variable named own.
DD: own has to have it
YK: I only care about one scenario: coma separated private name scenarios. Im willing to restrict the grammar for those cases. We should not add arbitrary restrictions.
DD: If you have own methods, it will have to have the new line restrictions.
MM: Evewhere where you have an identifier name that means a new property/fields you can use the computed property fields for same name?
DD: Yes
MM: Including the computed property its ok.
JM: We have consensus en no own. The second things is, do we need the ability to make this keyword optional?
JM: What do we need for this proposal to be in stage 3?
(process discussion, lol)
own(Domenic Denicola)
DD: Got to stage 3, but then there was implementation feedback that we had some issues.
DD: As background: We don't want "promises for promises", but you could explicitly yield a rejected promise from an async iterator
Consider
async function f * () { yield 1; yield Promise.reject(2); yield 3; }
Because 'yield' does not unwrap, someone consuming the sequence manually will get a rejected promise but the generator will complete normally. This differs from sync generators, which stop if there's an exception.
If you iterate with for-await-of over an async iterator which returns a rejected promise, rather than throwing, the for-await-of will re-throw the exception from the rejected promise immediately, leaving the async iterator paused, which means it doesn't have the chance to clean up resources e.g. with a finally
MM: I don't like option 1 (don't unwrap rejection) WD: Would it be any different in yield and yield await?
RBN: When you yields a promise that is rejected, by the time it resolved it will be resolved.
DD: Proposal: yielding just stores the raw value of what you yielded (i.e. no unwrapping), and if you use 'next' manually you need to deal with it, but for-await-of unwraps. so manually consuming with 'next' gives you promises, but for-await-of gives you the values, and rethrows if it hits a rejected promise
DD: Problem: this means library authors can't use next without a lot of work. Also means that yield* is not like for-await-of and manually yielding each value
RBN: If I throw in a generator, it should go over the boundary. Does not hit finally blocks (?)
DD: The problem is yielding a rejected promise.
Adam: The special case is that for a iterator if next throws, iterator is not closed. If is a generator, thats fine, and im not totally combinced in the simmetry.
DD: To avoid the resource leak we can avoid calling return.
YK: Restated option 3: yield has the same semantics as yield await in an async generator
RW: Have you asked CaitP?
DD: Yes, she thinks it would be easier to implement and therefore likes it.
RW: Good, same.
MM: My favorite option is option3, despite previously liking one of the other options
WH: I also favor option 3.
(room in general): I favor option 3
(Brian Terlson, Ron Buckton)
RBN: (walking through slides)
Motivations
Goals
Source/Sink
Source
Owned by caller - Can share entangled Sink with multiple callees - Initiates cancellation signal
Sink
Received by callee
Can observe cancellation state
Cannot initiate cancellation signal on Source
Callee A cannot interfere with Callee B using the same Sink
...just look at the slides...
Promise As A Token
YK: When Domenic originally proposed, there was a ... (I didn't catch the rest of that)
RBN: Need to revisit
DD: Disagreed with explanation of https://github.com/whatwg/dom/pull/437
(reached some slide with a callable constructor)
YK: I thought we were avoiding
RW: callable constructors can't be subclassed
CancellationToken API Slide
MM: (question about the phase that a callback is called, missed which, but RBN confirmed that it did whatever it was Mark asked about)
No time left, so not pushing Stage 1
YK: not sure if we should accept wholesale?
RBN: borrows heavily from the established .net APIs
(Daniel Ehrenberg)
DE: Made the changes, ready?
WH: I reviewed it this morning, at which point I found that it did not have the changes reflecting our decisions.
DE: I made the changes during today's lunch.
(Jafar Husain)
JH: (working through slides, returned to original proposal)
... slides, slides, slides
AK: Why does this need to be in the standard library? No answer to that yet.
MM: Promises were popular and could be implemented in library code, but it was a high value to users
MM: This is going into Angular
YK: The way Angular is using observable is, in my opinion, wrong.
MM: Where does this fit in?
YK: The DOM
DD: There are also libraries where Observable has gone in and then out.
SM: Never fully integrated into React.
YK: Observables fundamentally push, where pull is proven to be more effective
KM: Are there use cases in Node.js?
API: Bloomberg data (more here, Andrew please fill in)
DD: (examples of DOM apis that make sense in DOM and Node, but not in language)
WH: Will there be risk of Observable identifier clashes, with scripts resolving it and picking up our implementation and thinking it's one of the external library ones which might behave differently?
AK: There is an interest in an Observable, but no one wants to deal with "which one"
JH: Believe this is fundamental
MM: Support that. Prior to Promises, we were designing a sequential iterative language; since Promises we're designing a language for asynchronous programming as well. We are figuring out what the toolkit is of basic asynchronous programming abstractions. Asynchronous iterators give us pull streams. Observables give us push streams. Both seem to be necessary, serving broad needs.
AK: Then why not Streams?
DD: async iterators
Stage 2?
YK: Concerned that this won't make past Stage 3. Similar issue to cancellation token?
AK: Not the only person with concerns
DE: Want to see more interaction with host environments
YK: Wondering if DOM will use this to replace event emitter in the DOM?
RW: As in literally replacing EventTarget?
DD: There is a better, backward-compatible path for that.
DE: Concerns about where it fits in host environments
AK: Stronger concerns: will this be the thing actually used in hosts?
RW: (shared experience with Observable "zealotry" in the case of Generic Sensor)