Sorry, but I don’t exactly get the outcome of the object destructuring discussion when it came to own vs enumerable properties. I see Allen Wirfs-Brock arguing against using only own properties, but then a few sentences later stating “ownness is clear”. Huh?
FWIW, to this day I don’t get the hatred of inheritance. As long as property access takes inheritance into account, people are screwed when they mess with Object.prototype. Try running your code on Node.js with Object.defineProperty(Object.prototype, “error”, {value: function() {}}) and see how well it silences almost all errors. Or do the same with any obj.property name you find in your code.
All such proposals make using prototypical inheritance for the rest of us complicated — there might be code that filters out valid [inherited] properties as a by-product of convenience.
Andri
Sorry, but I don’t exactly get the outcome of the object destructuring discussion when it came to own vs enumerable properties. I see Allen Wirfs-Brock arguing against using only own properties, but then a few sentences later stating “ownness is clear”. Huh?
FWIW, to this day I don’t get the hatred of inheritance. As long as property access takes inheritance into account, people are screwed when they mess with Object.prototype. Try running your code on Node.js with Object.defineProperty(Object.prototype, “error”, {value: function() {}}) and see how well it silences almost all errors. Or do the same with *any* obj.property name you find in your code.
All such proposals make using prototypical inheritance for the rest of us complicated — there might be code that filters out valid [inherited] properties as a by-product of convenience.
Andri
On Oct 3, 2014, at 16:23, Rick Waldron <waldron.rick at gmail.com> wrote:
> # September 25 2014 Meeting Notes
>
> Brian Terlson (BT), Allen Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo (EF), Jeff Morrison (JM), Jonathan Turner (JT), Sebastian Markbage (SM), Istvan Sebestyen (phone) (IS), Erik Arvidsson (EA), Brendan Eich (BE), Domenic Denicola (DD), Peter Jensen (PJ), Eric Toth (ET), Yehuda Katz (YK), Dave Herman (DH), Brendan Eich (BE), Simon Kaegi (SK), Boris Zbarsky (BZ), Andreas Rossberg (ARB), Caridy Patino (CP), Niko Matsakis (NM), Mark Miller (MM), Matt Miller (MMR), Jaswanth Sreeram (JS)
>
>
> ## 5.8 Object Rest Destructuring and Spread Properties
>
> (Sebastian Markbage)
>
> Spec https://github.com/sebmarkbage/ecmascript-rest-spread
>
> Request Slides
>
>
> SM: Update: own properties?
> - Need to be own properties
>
> ```js
> Object.prototype.hostile = 1;
>
> let { ...o } = {};
>
> let o = { ...{} };
>
> o.hostile; // 1
> o.hasOwnProperty("hostile"); // true
> ```
>
>
> MM: clarifies hostile vs. accidental
>
> MM: When does Object.assign do toMethod?
>
> RW: Never. That was designed for Object.define/mixin
>
> AWB: Confirm
>
> SM: Mental model:
>
> ```js
> ...o
>
> expands keys = Object.keys(o) to
> o[keys[0]], o[keys[1]], o[keys[2]]
> ```
>
>
> Security Consideration?
>
> Syntax introduces a new way to determine "ownness" without going through (patchable) library functions:
>
> - Object.prototype.hasOwnProperty
> - Object.keys
>
> MM: Explains that SES is capable of patching the above by replacing these APIs. Rewriting syntax is undesirable.
>
> Discussion about ownness and enumerability
>
> YK:
>
> MM: If we proceed assuming weak maps are not slow, then they won't be (i.e., browsers will finally switch to the transposed representation)
>
> YK: As a lib impl, weak maps are slow and I have no reason to believe they'll be fast in the near future, so I won't use them
>
> AWB: Not our job to design lang around what things are slow today
>
> ARB: concerned about proliferating the use of enumerability
>
> AWB: Had this discussion many times. Enumerable is obselete reflection of semantics of for-in. Don't want people to use enumerable to start meaning new things.
>
> YK: We agreed it's obselete function of for-in, but it is widely used. So can't change the way it's assumed to work
>
> AWB: Today, in es5, enumerability used as a way to deal with copying
>
> MM: WRT proposal on table, it is a copying API. So you're agreeing with the fact that the proposal on table is sensitive to enumerability
>
> YK: Yes
>
> ARB: This is only really useful for record copying
>
> AWB: Let's talk about own again. This is an extension of obj destructuring -- which, as it exists today, does not restrict prop accesses to own properties.
>
> AWB: However, it does restrict/ignores enumerability
>
> AWB: Implication of this being own: You couldn't use a tree structure to represent a set of values:
>
> ```js
> BaseOpts = {__proto__: null, o1: 1, o2: 2, o3: 3, ... oN: n};
> ThisTime = {__proto__: BaseOpts, o7: 14};
> foo(ThisTime);
> ```
>
> AWB: Now, inside of Foo...
>
> AWB: Since you're excluding non-enumerables, normally things in Object.prototype are excluded. So not worried about picking up those things
>
> YK: You're worried about picking up someone's old prototype extensions. It's true people could do that, but in practice people don't
>
> MM: We have several arguments that say own is what's expected
>
> MM: In ES3, assumption is there's all sorts of gunk on Object.prototype because no way to get rid of it. Reason it was restricted to own-ness was because there was a desire to not iterate stuff on Object.prototype
>
> YK: There's a notion of copying today that means "non-enum, own"
>
> AWB: Notions in JS today are diff from notions 5 years ago and 5 years from now
>
> MM: We can't accomodate legacy in this way forever. We're in a history dependent trap, we should make this (enumerable + own)?[verify]
>
> AWB: How does this play with/needed in the context of other extensions? For example, record types vs property bags to represent options. If people use typed objects vs regular, would expectations change for this syntax?
>
> SM: Brings up another proposal: Records (new proposal) in same realm as TypedObjects, but simpler syntactically
>
> AWB: In the past, when focusing in on a microfeature, it makes sense. But when looking at features more broadly those proposals make sense differently. There are enough things that are coming soon that need to be considered here as well
>
> MM: This feature is on the same "future table" as those other things, so they'll be considered together as we move forward.
>
> SM: Record types don't have a concept of prototype chain, so not even a consideration; So this should operate consistently between those and regular objects
>
> SM: (tries to move on to a new slide)
>
> ARB: so ownness is clear, but are we settled on enumerability?
>
> MM: yes
>
> SM: I think it should be settled, and any argument against the enumerability policy here also appllies to Object.assign
>
> YK: Object.assign is meant to be a widely-used mechanism for copying
>
> ARB: I see your point, but am still concerned...
>
> YK: I think the problem is that people don't like enumerability. I don't like enumerability. But enumerability is how you design copying behavior in this language.
>
>
> AWB: Is this feature valuable enough to make this as syntax rather than something that lives in a library
>
> MM: Need a functional mechanism for updating records
>
> AWB: This seems like a nice feature, but not sure why this should make it in over other features.
>
> YK: Symmetrical with destructuring, so easy to understand.
>
> MM: This seems like a smaller burden on programmer psychology
>
> AWB: Well, it is a burden. Spread and rest used to be an enumerable list of things, and now we have ... mean something else.
>
> MM: There is a cognitive cost, but because of the analogy it's much less than a new feature.
>
> MM: When we previously produced large specifications (through ES6) we used to determine the complexity everything together. Possible that the yearly release will make it more difficult to budget for complexity.
>
> DH: Also makes it harder to say no to a feature that makes sense locally and has gone through the process.
>
> MM: We should allow for something to get rejected even after it has gotten through all the stages.
>
> YK: It's an implicit requirement. Should make it an explicit requirement.
>
> MM: Agree.
>
> DH: Recognize that this feature is fitting in an existing syntactic space and is rounding out a syntax that already exists.
>
> ARB: It's subtly different...
>
> DH: You'll have to learn it
>
> ```
> function ComponentChild({ isFoo, ...rest }) {
> var type = isFoo ? 'foo' : 'bar';
> return ComponentBase({ ... rest, type });
> }
> ```
>
> AWB: What happens if rest is an array?
>
> MM/SM: It creates the enumerable array properties.
>
> AWB: But we use iterators.
>
> MM: It should be dependent on the syntactic thing containing the .... In an object literal, ... will enumerate properties.
>
> SM: Stage 1?
>
>
> #### Conclusion/Resolution
>
> - Stage 1 approval
>
>
> AWB: Be sure to mark agenda items that want to advance with some kind of notation, this will help to get pre-meeting attention.
>
> (Confirmed by all)
>
> RW: Use the rocketship icon
>
> YK: I feel like the rocketship icon should be for proposals which are ready to launch
>
> DD: If you bikeshed on the rocketship icon I will change it to a bikeshed icon.
>
> RW: :D
>
>
> ## Loader pipeline
>
> AWB: Working on module spec. Questions: Loader pipeline. Can we simplify modules for ES spec?
>
> "A.js"
> ```js
> export let g = 5;
> import f from "B.js";
> f(g);
> ```
>
> "B.js"
> ```js
> import g from "A.js";
> export function f(z) {
> return z * g;
> };
> ```
>
> AWB: Essential in ES6 that the semantics of above example code is well defined.
> - None of it depends on how the loader is parameterized.
> - Strictly at the declarative level of the language
>
> BE: So what goes on the ES side?
>
> AWB: Syntax and semantics (static, linking, and runtime) of declarative modules. Linking does have to be there, but it's linking at the declarative level of the lang.
>
> DH: So you have some small number of low-level integration hooks in ES that expose enough for browser implementors design and build loader pipeline themselves?
>
> AWB: They're at the same level as the other host hooks that we have
>
> AWB: The only host hook is the one that says "there's a request for a module name (from referrer), give me the source code"
>
> DH: To clarify: I think what Allen means by "hook" is not user-visible, it's visible to an engine. It's a spec device used to factor out the pipeline. It's not available to user code, just to the internal semantics of the pipeline.
>
> MM: And we can move the pipeline into a separate spec.
>
> EF: "Authoring and runtime"
> - Authoring: actual writing of modules
> - Runtime: the loader
>
> (Discussion about Loader polyfill)
>
> (Discussion of how the loader spec would be a separate document)
>
> YK: The loader pipeline will be done in a "living spec" (a la HTML5) so that Node and the browser can collaborate on shared needs.
>
> #### Conclusion/Resolution
>
> Loader pipeline goes into a separate spec: living document that deals with integration
>
>
> AWB: Retitle? ECMAScript 2015 (6th edition), and so on
>
>
>
> ## Train Schedule
>
> DH: Let's define the schedule
>
> YK: ES2015 is the first train.
>
> ## Types
> (Jonathan Turner)
>
> type_annotations.pdf
>
> JT: Goals
> - Short term
> - Reserve syntax used by TypeScript, Flow, etc. for some form of annotation
> - Venue for collaboration among interested committtee members
> - Long term
> - Consensus on a shared syntax fr many varied type annotation implementations
> - Consensus on
>
> - Additionally, a shared syntax for interface definition for documening API boundaries (.d.ts files)
>
>
> Examples & Demo
>
> ...
>
>
> Rationale: Why Type Annotations?
>
> - Toolability
> - Closure
> - TypeScript
> - Flow
> - JSDoc
> - Performance
> - Asm.js
> - Hidden classes/runtime inferences
> - API specification
> - DefinitelyTyped/.d.ts
> - WebIDL
> - JSDoc
> - Runtime checks/Guarantees
> - Guards
> - Contracts
>
>
>
> Rationale: Why Standardize?
>
> copy from slides
>
>
> JT: Looking for Stage 0 blessing to pursue type annotations a la TypeScript and .d.ts file definitions.
>
> MM: You've presented annotation, what about checking?
>
> JT: Type checking not defined
> - mention of python type design
>
> MM: I'm not familiar
>
> JT: TS, Flow have different type checking rules that will hopefully emerge
>
> DD: Draws comparison to divergent promise implementations that were successfully unified
>
> ARB: the result is rather terrible
>
> MM: The fact that `.then` came together was a miracle and shouldn't be a practice.
>
> DH: If we want to agree on reserved syntax that currently has no legal JavaScript overlap, that is it fails, not ignored. If such a thing can be agreed on, then different groups can develop around the syntax divergently. Cannot expect to reserve _behavior_. The rationale slide is far too vague.
> - Goal: TS and Flow are taking a risk where TC39 could easily standardize on a syntax that invalidates those project's uses
>
> JM: no attempt to standardize the entire syntax
> - Python: imagine similar approach
> - annotations
> - arbitrary expressions evaluated then attached to the function object
> - language doesn't need to use them in runtime
> - tooling may use them
> - allows both static and runtime tooling
>
> - (this point was about third party consumption of type information, needs to be filled in)
> - no guarantee that TS or Flow won't continue extending the grammar
>
>
> YK: If you give type checks anything but an error, you can't create different semantics later
>
> DH/YK/DD: mixed discussion re: history of type design sets constraints
>
> JM: We need to start making these things possible by putting the capability in the language
>
> STH: underestimating the complexity (refers to DH work)
> - Types seem to be doing well in their current form (compile to JS)
> - what is the problem we're trying to solve here?
> - RE: Python, the underspecification is already causing problems w/ competing groups
>
> JM: to move forward we really need a space that's reserved
>
> DD: Wouldn't have proposed this as types, it's closer to parameter types and returns
>
> YK: decorators suffered the same syntactic space arguments.
>
> MM: I'd propose that you enter Stage 0 with TypeScript.
> - TS made a choice and proved that this choice has utility.
> -
>
> DH: Don't need TC39
>
> JM: How do we know when it's time to come to TC39? We need TC39 to help with progress
>
> JM: Various projects working toward similar goals: TypeScript, Safe TypeScript, Closure Compiler, IBM has a project, Flow. Ongoing research that should be collaborating and coordinating with TC39
>
> BE: codify annotation grammar, build object that you can reflect on. Not ready to do that.
> - Make reserved syntax, we can do that.
>
> MM: It's just a 16.1 restriction on extensions.
>
> BE: ECMAScript allows and always has allowed implementers to make syntax extensions.
>
> YK: Nashorn adds "#" comment
>
> DH: Difference between TS, Flow and Nashorn
>
> RW: (couldn't say outloud) Nashorn changed JS syntax; TS, Flow compile to JS
>
> JT: Just want to reserve/restrict certain basic block of syntax that projects can use
>
> DH: Syntax reservation has value. Attempting to define some minimal semantics is a bad idea.
>
> BE: (copy grammar from whiteboard)
>
> JM: Would like to be able to point to document for this
>
> AWB: Some kind of "statement of future direction" document
>
> RW: Similar to Future Reserved Word, it's a "Future Reserved Grammar/Syntax"
>
> (agreement)
>
> AWB: (explanation of how this could work and documented)
>
> SM: Concrete spec proposal and what goes into next release?
>
> - Will need to converge eventually
> - Can do it on our own
> - Could do this as part of the TC39 process
>
> RW: suggest proposal Future Reserved Grammar doc for next meeting to ask for Stage 0
>
> (discussion about responsibility)
>
> JM: Seems like "type systems of some kind" have interest. Start conservatively, Future Reserved Grammar/Syntax etc, and build from there.
>
> JT: Stage -1: reserved grammar
>
> DH: Stage 0 for this:
>
> - Reserve syntax via Future Reserved Grammar/Syntax
> - Does not compute
> - Is an error
> - cannot ever create an incompatible change
>
>
> AWB: Make a motion that TC39 is creating an area of research in types and type annotations and all members are welcome to get involved?
>
> DH: As long as we maintain balance and prioritize.
>
> BE: Concern about opening the door too wide.
>
> SK: What about work on extensions that _require_ semantics?
>
> ARB: you can't know what type syntax you need without knowing the semantics. In particular, Python's type syntax as just expression syntax doesn't scale, you generally need different constructs on both levels
>
> BE: for example generic brackets
>
> DH: What is the grammar?
>
> JM: (python expression example)
>
> What's the conclusion?
>
> ARB: make colon syntax reserved
>
> RW: there's more to it!
>
>
> #### Conclusion/Resolution
>
> - Create Future Reserved Syntax (extension restrictions)
> - Syntax error
> - Define `a: T<U>`
>
>
>
>
> ## 5.10 global.asap for enqueuing a microtask
>
> (Domenic Denicola and Brian Terlson)
>
> DD: Want enqueue microtask, which is capable of starving the eventloop
>
> AWB: As spec writer, I don't know what this is
>
> YK: In JS there is a frame, it loops
>
> MM: Is the queue, the same queue that promises queue into?
>
> DD: Yes
>
> YK: Want a way to queue a job that's guaranteed to run before all other tasks
>
> AWB: There are spec mechanisms that define ways to create a job in the queue
>
> DD: Don't care what it's called just want it to exprss the intent, which is faster than setImmediate
>
> Discussion about the semantics and defining the order of execution. MM is objecting
>
> YK: A non-normative note?
>
> DD: No, if it's non-normative I don't care, I want it normative
>
> Issues about host interference with expected run-to-completion model
>
> AWB: present job and job queue mechanism intended to describe the two things we needed to describe and knew there would elaboration. Go ahead and develop a proposal.
>
> YK: Concerned that explanation problems lie in using browser terminology
> - Micro task is part of run to completion
> - Task queue is not
>
> AWB: jobs run to completion
>
> MM: Job queues are always async by definition
> - We have terminology, please use the correct terminology
>
> YK: Ok, won't use "synchronous"
>
> MM; multiple queues in a priority mode
> - You want the microtask queue to have a strictly higher priority
> - We may even specify priority queues
>
> DD: Want to specify `global.asap`
> - Accepts a function
> - Enqueues in a high priority queue
>
> DH: Think this is awesome
> - We need a generic model for job scheduling.
>
> #### Conclusion/Resolution
>
> - Stage 0:
> - Some way to publish into a queue
> - priority queueing
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141004/bd8e133f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4786 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141004/bd8e133f/attachment-0001.p7s>
Sorry, but I don’t exactly get the outcome of the object destructuring discussion when it came to own vs enumerable properties. I see Allen Wirfs-Brock arguing against using only own properties, but then a few sentences later stating “ownness is clear”. Huh?
FWIW, to this day I don’t get the hatred of inheritance. As long as property access takes inheritance into account, people are screwed when they mess with Object.prototype. Try running your code on Node.js with Object.defineProperty(Object.prototype, “error”, {value: function() {}}) and see how well it silences almost all errors. Or do the same with any obj.property name you find in your code.
All such proposals make using prototypical inheritance for the rest of us complicated — there might be code that filters out valid [inherited] properties as a by-product of convenience.
Andri
Sorry, but I don’t exactly get the outcome of the object destructuring discussion when it came to own vs enumerable properties. I see Allen Wirfs-Brock arguing against using only own properties, but then a few sentences later stating “ownness is clear”. Huh? FWIW, to this day I don’t get the hatred of inheritance. As long as property access takes inheritance into account, people are screwed when they mess with Object.prototype. Try running your code on Node.js with Object.defineProperty(Object.prototype, “error”, {value: function() {}}) and see how well it silences almost all errors. Or do the same with *any* obj.property name you find in your code. All such proposals make using prototypical inheritance for the rest of us complicated — there might be code that filters out valid [inherited] properties as a by-product of convenience. Andri On Oct 3, 2014, at 16:23, Rick Waldron <waldron.rick at gmail.com> wrote: > # September 25 2014 Meeting Notes > > Brian Terlson (BT), Allen Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo (EF), Jeff Morrison (JM), Jonathan Turner (JT), Sebastian Markbage (SM), Istvan Sebestyen (phone) (IS), Erik Arvidsson (EA), Brendan Eich (BE), Domenic Denicola (DD), Peter Jensen (PJ), Eric Toth (ET), Yehuda Katz (YK), Dave Herman (DH), Brendan Eich (BE), Simon Kaegi (SK), Boris Zbarsky (BZ), Andreas Rossberg (ARB), Caridy Patino (CP), Niko Matsakis (NM), Mark Miller (MM), Matt Miller (MMR), Jaswanth Sreeram (JS) > > > ## 5.8 Object Rest Destructuring and Spread Properties > > (Sebastian Markbage) > > Spec https://github.com/sebmarkbage/ecmascript-rest-spread > > Request Slides > > > SM: Update: own properties? > - Need to be own properties > > ```js > Object.prototype.hostile = 1; > > let { ...o } = {}; > > let o = { ...{} }; > > o.hostile; // 1 > o.hasOwnProperty("hostile"); // true > ``` > > > MM: clarifies hostile vs. accidental > > MM: When does Object.assign do toMethod? > > RW: Never. That was designed for Object.define/mixin > > AWB: Confirm > > SM: Mental model: > > ```js > ...o > > expands keys = Object.keys(o) to > o[keys[0]], o[keys[1]], o[keys[2]] > ``` > > > Security Consideration? > > Syntax introduces a new way to determine "ownness" without going through (patchable) library functions: > > - Object.prototype.hasOwnProperty > - Object.keys > > MM: Explains that SES is capable of patching the above by replacing these APIs. Rewriting syntax is undesirable. > > Discussion about ownness and enumerability > > YK: > > MM: If we proceed assuming weak maps are not slow, then they won't be (i.e., browsers will finally switch to the transposed representation) > > YK: As a lib impl, weak maps are slow and I have no reason to believe they'll be fast in the near future, so I won't use them > > AWB: Not our job to design lang around what things are slow today > > ARB: concerned about proliferating the use of enumerability > > AWB: Had this discussion many times. Enumerable is obselete reflection of semantics of for-in. Don't want people to use enumerable to start meaning new things. > > YK: We agreed it's obselete function of for-in, but it is widely used. So can't change the way it's assumed to work > > AWB: Today, in es5, enumerability used as a way to deal with copying > > MM: WRT proposal on table, it is a copying API. So you're agreeing with the fact that the proposal on table is sensitive to enumerability > > YK: Yes > > ARB: This is only really useful for record copying > > AWB: Let's talk about own again. This is an extension of obj destructuring -- which, as it exists today, does not restrict prop accesses to own properties. > > AWB: However, it does restrict/ignores enumerability > > AWB: Implication of this being own: You couldn't use a tree structure to represent a set of values: > > ```js > BaseOpts = {__proto__: null, o1: 1, o2: 2, o3: 3, ... oN: n}; > ThisTime = {__proto__: BaseOpts, o7: 14}; > foo(ThisTime); > ``` > > AWB: Now, inside of Foo... > > AWB: Since you're excluding non-enumerables, normally things in Object.prototype are excluded. So not worried about picking up those things > > YK: You're worried about picking up someone's old prototype extensions. It's true people could do that, but in practice people don't > > MM: We have several arguments that say own is what's expected > > MM: In ES3, assumption is there's all sorts of gunk on Object.prototype because no way to get rid of it. Reason it was restricted to own-ness was because there was a desire to not iterate stuff on Object.prototype > > YK: There's a notion of copying today that means "non-enum, own" > > AWB: Notions in JS today are diff from notions 5 years ago and 5 years from now > > MM: We can't accomodate legacy in this way forever. We're in a history dependent trap, we should make this (enumerable + own)?[verify] > > AWB: How does this play with/needed in the context of other extensions? For example, record types vs property bags to represent options. If people use typed objects vs regular, would expectations change for this syntax? > > SM: Brings up another proposal: Records (new proposal) in same realm as TypedObjects, but simpler syntactically > > AWB: In the past, when focusing in on a microfeature, it makes sense. But when looking at features more broadly those proposals make sense differently. There are enough things that are coming soon that need to be considered here as well > > MM: This feature is on the same "future table" as those other things, so they'll be considered together as we move forward. > > SM: Record types don't have a concept of prototype chain, so not even a consideration; So this should operate consistently between those and regular objects > > SM: (tries to move on to a new slide) > > ARB: so ownness is clear, but are we settled on enumerability? > > MM: yes > > SM: I think it should be settled, and any argument against the enumerability policy here also appllies to Object.assign > > YK: Object.assign is meant to be a widely-used mechanism for copying > > ARB: I see your point, but am still concerned... > > YK: I think the problem is that people don't like enumerability. I don't like enumerability. But enumerability is how you design copying behavior in this language. > > > AWB: Is this feature valuable enough to make this as syntax rather than something that lives in a library > > MM: Need a functional mechanism for updating records > > AWB: This seems like a nice feature, but not sure why this should make it in over other features. > > YK: Symmetrical with destructuring, so easy to understand. > > MM: This seems like a smaller burden on programmer psychology > > AWB: Well, it is a burden. Spread and rest used to be an enumerable list of things, and now we have ... mean something else. > > MM: There is a cognitive cost, but because of the analogy it's much less than a new feature. > > MM: When we previously produced large specifications (through ES6) we used to determine the complexity everything together. Possible that the yearly release will make it more difficult to budget for complexity. > > DH: Also makes it harder to say no to a feature that makes sense locally and has gone through the process. > > MM: We should allow for something to get rejected even after it has gotten through all the stages. > > YK: It's an implicit requirement. Should make it an explicit requirement. > > MM: Agree. > > DH: Recognize that this feature is fitting in an existing syntactic space and is rounding out a syntax that already exists. > > ARB: It's subtly different... > > DH: You'll have to learn it > > ``` > function ComponentChild({ isFoo, ...rest }) { > var type = isFoo ? 'foo' : 'bar'; > return ComponentBase({ ... rest, type }); > } > ``` > > AWB: What happens if rest is an array? > > MM/SM: It creates the enumerable array properties. > > AWB: But we use iterators. > > MM: It should be dependent on the syntactic thing containing the .... In an object literal, ... will enumerate properties. > > SM: Stage 1? > > > #### Conclusion/Resolution > > - Stage 1 approval > > > AWB: Be sure to mark agenda items that want to advance with some kind of notation, this will help to get pre-meeting attention. > > (Confirmed by all) > > RW: Use the rocketship icon > > YK: I feel like the rocketship icon should be for proposals which are ready to launch > > DD: If you bikeshed on the rocketship icon I will change it to a bikeshed icon. > > RW: :D > > > ## Loader pipeline > > AWB: Working on module spec. Questions: Loader pipeline. Can we simplify modules for ES spec? > > "A.js" > ```js > export let g = 5; > import f from "B.js"; > f(g); > ``` > > "B.js" > ```js > import g from "A.js"; > export function f(z) { > return z * g; > }; > ``` > > AWB: Essential in ES6 that the semantics of above example code is well defined. > - None of it depends on how the loader is parameterized. > - Strictly at the declarative level of the language > > BE: So what goes on the ES side? > > AWB: Syntax and semantics (static, linking, and runtime) of declarative modules. Linking does have to be there, but it's linking at the declarative level of the lang. > > DH: So you have some small number of low-level integration hooks in ES that expose enough for browser implementors design and build loader pipeline themselves? > > AWB: They're at the same level as the other host hooks that we have > > AWB: The only host hook is the one that says "there's a request for a module name (from referrer), give me the source code" > > DH: To clarify: I think what Allen means by "hook" is not user-visible, it's visible to an engine. It's a spec device used to factor out the pipeline. It's not available to user code, just to the internal semantics of the pipeline. > > MM: And we can move the pipeline into a separate spec. > > EF: "Authoring and runtime" > - Authoring: actual writing of modules > - Runtime: the loader > > (Discussion about Loader polyfill) > > (Discussion of how the loader spec would be a separate document) > > YK: The loader pipeline will be done in a "living spec" (a la HTML5) so that Node and the browser can collaborate on shared needs. > > #### Conclusion/Resolution > > Loader pipeline goes into a separate spec: living document that deals with integration > > > AWB: Retitle? ECMAScript 2015 (6th edition), and so on > > > > ## Train Schedule > > DH: Let's define the schedule > > YK: ES2015 is the first train. > > ## Types > (Jonathan Turner) > > type_annotations.pdf > > JT: Goals > - Short term > - Reserve syntax used by TypeScript, Flow, etc. for some form of annotation > - Venue for collaboration among interested committtee members > - Long term > - Consensus on a shared syntax fr many varied type annotation implementations > - Consensus on > > - Additionally, a shared syntax for interface definition for documening API boundaries (.d.ts files) > > > Examples & Demo > > ... > > > Rationale: Why Type Annotations? > > - Toolability > - Closure > - TypeScript > - Flow > - JSDoc > - Performance > - Asm.js > - Hidden classes/runtime inferences > - API specification > - DefinitelyTyped/.d.ts > - WebIDL > - JSDoc > - Runtime checks/Guarantees > - Guards > - Contracts > > > > Rationale: Why Standardize? > > copy from slides > > > JT: Looking for Stage 0 blessing to pursue type annotations a la TypeScript and .d.ts file definitions. > > MM: You've presented annotation, what about checking? > > JT: Type checking not defined > - mention of python type design > > MM: I'm not familiar > > JT: TS, Flow have different type checking rules that will hopefully emerge > > DD: Draws comparison to divergent promise implementations that were successfully unified > > ARB: the result is rather terrible > > MM: The fact that `.then` came together was a miracle and shouldn't be a practice. > > DH: If we want to agree on reserved syntax that currently has no legal JavaScript overlap, that is it fails, not ignored. If such a thing can be agreed on, then different groups can develop around the syntax divergently. Cannot expect to reserve _behavior_. The rationale slide is far too vague. > - Goal: TS and Flow are taking a risk where TC39 could easily standardize on a syntax that invalidates those project's uses > > JM: no attempt to standardize the entire syntax > - Python: imagine similar approach > - annotations > - arbitrary expressions evaluated then attached to the function object > - language doesn't need to use them in runtime > - tooling may use them > - allows both static and runtime tooling > > - (this point was about third party consumption of type information, needs to be filled in) > - no guarantee that TS or Flow won't continue extending the grammar > > > YK: If you give type checks anything but an error, you can't create different semantics later > > DH/YK/DD: mixed discussion re: history of type design sets constraints > > JM: We need to start making these things possible by putting the capability in the language > > STH: underestimating the complexity (refers to DH work) > - Types seem to be doing well in their current form (compile to JS) > - what is the problem we're trying to solve here? > - RE: Python, the underspecification is already causing problems w/ competing groups > > JM: to move forward we really need a space that's reserved > > DD: Wouldn't have proposed this as types, it's closer to parameter types and returns > > YK: decorators suffered the same syntactic space arguments. > > MM: I'd propose that you enter Stage 0 with TypeScript. > - TS made a choice and proved that this choice has utility. > - > > DH: Don't need TC39 > > JM: How do we know when it's time to come to TC39? We need TC39 to help with progress > > JM: Various projects working toward similar goals: TypeScript, Safe TypeScript, Closure Compiler, IBM has a project, Flow. Ongoing research that should be collaborating and coordinating with TC39 > > BE: codify annotation grammar, build object that you can reflect on. Not ready to do that. > - Make reserved syntax, we can do that. > > MM: It's just a 16.1 restriction on extensions. > > BE: ECMAScript allows and always has allowed implementers to make syntax extensions. > > YK: Nashorn adds "#" comment > > DH: Difference between TS, Flow and Nashorn > > RW: (couldn't say outloud) Nashorn changed JS syntax; TS, Flow compile to JS > > JT: Just want to reserve/restrict certain basic block of syntax that projects can use > > DH: Syntax reservation has value. Attempting to define some minimal semantics is a bad idea. > > BE: (copy grammar from whiteboard) > > JM: Would like to be able to point to document for this > > AWB: Some kind of "statement of future direction" document > > RW: Similar to Future Reserved Word, it's a "Future Reserved Grammar/Syntax" > > (agreement) > > AWB: (explanation of how this could work and documented) > > SM: Concrete spec proposal and what goes into next release? > > - Will need to converge eventually > - Can do it on our own > - Could do this as part of the TC39 process > > RW: suggest proposal Future Reserved Grammar doc for next meeting to ask for Stage 0 > > (discussion about responsibility) > > JM: Seems like "type systems of some kind" have interest. Start conservatively, Future Reserved Grammar/Syntax etc, and build from there. > > JT: Stage -1: reserved grammar > > DH: Stage 0 for this: > > - Reserve syntax via Future Reserved Grammar/Syntax > - Does not compute > - Is an error > - cannot ever create an incompatible change > > > AWB: Make a motion that TC39 is creating an area of research in types and type annotations and all members are welcome to get involved? > > DH: As long as we maintain balance and prioritize. > > BE: Concern about opening the door too wide. > > SK: What about work on extensions that _require_ semantics? > > ARB: you can't know what type syntax you need without knowing the semantics. In particular, Python's type syntax as just expression syntax doesn't scale, you generally need different constructs on both levels > > BE: for example generic brackets > > DH: What is the grammar? > > JM: (python expression example) > > What's the conclusion? > > ARB: make colon syntax reserved > > RW: there's more to it! > > > #### Conclusion/Resolution > > - Create Future Reserved Syntax (extension restrictions) > - Syntax error > - Define `a: T<U>` > > > > > ## 5.10 global.asap for enqueuing a microtask > > (Domenic Denicola and Brian Terlson) > > DD: Want enqueue microtask, which is capable of starving the eventloop > > AWB: As spec writer, I don't know what this is > > YK: In JS there is a frame, it loops > > MM: Is the queue, the same queue that promises queue into? > > DD: Yes > > YK: Want a way to queue a job that's guaranteed to run before all other tasks > > AWB: There are spec mechanisms that define ways to create a job in the queue > > DD: Don't care what it's called just want it to exprss the intent, which is faster than setImmediate > > Discussion about the semantics and defining the order of execution. MM is objecting > > YK: A non-normative note? > > DD: No, if it's non-normative I don't care, I want it normative > > Issues about host interference with expected run-to-completion model > > AWB: present job and job queue mechanism intended to describe the two things we needed to describe and knew there would elaboration. Go ahead and develop a proposal. > > YK: Concerned that explanation problems lie in using browser terminology > - Micro task is part of run to completion > - Task queue is not > > AWB: jobs run to completion > > MM: Job queues are always async by definition > - We have terminology, please use the correct terminology > > YK: Ok, won't use "synchronous" > > MM; multiple queues in a priority mode > - You want the microtask queue to have a strictly higher priority > - We may even specify priority queues > > DD: Want to specify `global.asap` > - Accepts a function > - Enqueues in a high priority queue > > DH: Think this is awesome > - We need a generic model for job scheduling. > > #### Conclusion/Resolution > > - Stage 0: > - Some way to publish into a queue > - priority queueing > > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141004/bd8e133f/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4786 bytes Desc: not available URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141004/bd8e133f/attachment-0001.p7s>