Eric Ferraiuolo (EF), Caridy Patiño (CP), Michael Ficarra (MF), Peter Jensen (PJ), Domenic Denicola (DD), Jordan Harband (JHD), Chip Morningstar (CM), Brian Terlson (BT), John Neumann (JN), Dave Herman (DH), Yehuda Katz (YK), Jeff Morrison (JM), Lee Byron (LB), Daniel Ehrenberg (DE), Lars Hansen (LHN), Nagy Hostafa (NH), Michael Saboff (MLS), John Buchanan (JB), Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar Horwat (WH), Mark S. Miller (MM), Paul Leathers (PL), Sebastian Markbåge (SM), Zibi Braniecki (ZB), Andreas Rossberg (ARB), Ian Halliday (IH), Keith Miller (KM), Tim Disney (TD), Miško Hevery (MHY), Brad Green (BG), Kevin Smith (KS), Brad Nelson (BNN), JF Bastien (JFB), Shu-yu Guo (SYG), Rick Waldron (RW), Staś Małolepszy (STM), Dean Tribble (DT)
https://github.com/tc39/agendas/blob/master/2016/01.md
AWB: slide (Ecma to ISO)
AWB: ecma fast tracks it to become an ISO standard
AWB: slide (ECMAScript 2015 and beyond)
AWB: slide (the plan)
BT: Got a bunch of excellent editorial comments from JP22.
WH: The Japanese ISO delegation has been by far the most prolific in finding technical problems during our past ISO fast track reviews, but they were by no means the only ISO member to make productive comments.
BT: It's not clear if the other delegations are commenting or not. They feed comments via GitHub but we don't necessarily know if the GitHub input we're getting is coming from folks associated with ISO delegations. JP22 is conscientious in tagging their contributions, but I don't know if the other ones do.
BT: some of the issues have been editorial some are bugs or implementing concensus. Lots of pull requests for bug fixes.
WH: What are the natures of GitHub submissions from random entities to ES? For bug reports I'm not worried, but for more significant contributions there may be IPR issues.
BT: it is a heuristic, significant contributions is what matters. Some bug fixes could be considered contribution, if the contribution is significant they have to be a registered contributor.
AWB: it mostly comes into play for pull requests, but it is up to the editor
BT: not in theory, this is in practice, Largely contributions come from people in this room, but some substantial outside contributions have occured.
AWB: that is the general plan, addressing the ISO issue. So one final update that merely points to our documents.
AWB: slide (but still need something to fast-track as update to ISO/IEC 16262:2011)
AWB: slide, describing the content of the ecmascript suite.
BT: a downside I see, right now the fast-track process allows ISO members to provide feedback. If they do not see a document, would they provide feedback? I suspect this will result in less feedback from ISO. I don't believe that is fatal, but..
AWB: i believe that is true, but what alternative ?
DH: could we submit less frequently?
SP: seems very strange to get feedback on old versions, and not on the latest or new version
YK: does everyone agree that the standard is "official" is year old, would we want sony to feel required to implement an obsolete spec?
AWB: slide (ECMA to ISO)
AWB: should we provide a technical report for JTC1, that describes our process
WH: whats going to be in this document
AWB: the current draft is on the tc39 member area of the ecma site. (displays content on screen)
WH: is their more to this
AWB: no this is it
AWB: ISO people sent an email, that suggested we require a clause for a normative reference.
AWB: it is just a set of pointers
WH: This is just a bibliography without any paragraph that defines conformance. Once this gets an ISO standard number XYZ, what does it mean to conform to ISO standard XYZ? One can point to anything in a bibliography.
BT: do you mean, it should say must implement the entire spec
WH: Yes, the ISO pointer standard should have a short paragraph stating that conforming to the ISO standard is defined as conforming to the current ECMA standard that's referenced.
BT: we should say: If you conform to ecma-262, then you conform to the ISO spec
YK: are they ok with this?
AWB: it is actually their idea
BT: likely concerns exist, but something we can work out
YK: presumably those are one-shot things.
SP: everyone seems "in spirit" to be on-board, we just need to deal with some of the details.
BT: for this body we don't have to care, because we just do our thing. No more ISO fast tracking.
John: how does this impact 2016 release
AWB: it is entirely decoupled, normative rules dictate if no specific version is specified, it implies the current version
AWB: slide (Key dates)
BT: the way I want to do this, at the march meeting I want us to approve what is in master, or a snapshot. I don't want to make minor tech or editorial changes. I will make fixes if major issues exist, but otherwise I wish we can leave it as is. Leaving it as a tag
WH: What changes are you planning on making to the spec document between now and the April 1 deadline?
BT: Just small editorial changes and bug fixes.
WH: Which, if any, of the stage 3 or 4 proposals are you planning on adding into the document between now and then?
BT: None. As far as proposal-level features are concerned, the 2016 standard candidate spec will be what's in it today. Enjoy Array.prototype.includes (and the exponentiation operator).
AWB: have you discussed what will be in?
BT: changelogs have all the normative changes, I can go over those
AWB: we don't need to know, we should likely record exactly what are the new features.
BT: (lists features)
AWB: everything that applies here, applies to ecma 402 also. ecma 402 has to go through the process on the same dates, hopefully those editors are on top of that.
AWB: slide (draft stability)
BT: istvan wants a PDF, but will accept an HTML. Some may want a PDF, but it is merely a ctrl-p of the HTML. Those that want to use it, should be aware editorial changes may be more or less useless.
BT: I will give ecma a zip of a snapshot of the github repo.
YK: the PDF seems fine
BT: how are links
YK: people should use HTML
BT: the original PDF had links
YK: people should use HTML
WH: HTML has formatting issues.
WH: PDF needs links. It's much less useful without links.
AWB: some people may want to print this thing
BT: i believe those days are done
AWB: we should provide both
BT: companies could be hired to accomplish this
SP: is this a transition period, or will be do this forever
AWB: ecma would like to have the PDF
BT: ecma wants PDF, because of ISO requiring it, now that we no longer send the full spec to ISO, this may be fine.
AWB: ecma wants a zip file, that can run on a local machine and it has the full high fedility document.
BT: yup, they can host it.
AWB: they will want to insert some analytics
BT: I'll work with them to add that.
AWB: in the past, I have just copied their boiler plate
BT: do i take the snapshot on feb 26, lets pick a date.
AWB: Feb 29
BT: ok, thats a monday
BT: how about march 1
AWB: thats fine
BT: so if you have anything you want in the document, get it to me well before march 1
WH: How many files are in the HTML spec?
BT: 6. The HTML, CSS, diagrams, Javascript
WH: Why does the archival standard spec execute Javascript? Isn't that brittle?
BT: it isn't required, it merely improves the experience
(Allen Wirfs-Brock)
AWB: slide (Ecma Archival Issues)
AWB: slide (github)
SP: We can likely include a snapshot of issues/pull/comments requests as part of the release
YK: ecma position seems correct
SP: AWB are you going to do this
AWB: yes
AWB: slide (ES6 archives)
AWB: We need a strategy, small to medium (1 -> 2 weeks) could likely be covered by ecma.
AWB: tc39 reflector -> github private repo
AWB: István Sebestyén floated this, this is actually István's deck
AWB: root problem is as follows, how to pay for AWB to come to the meeting.... I am an instance of the problem. We have in the past invited experts, we cannot assume it is reasonable for them to cover this. Is their a way for a group like TC39, which is made up of orgs. Is there a means for it to provide some level of support to unaffiliated individuals who would be important contributors and such.
YK: how does one decide who is important and who is not
AWB: yes, lots of practical points to discuss
AWB: slide (ecma: type of participants in an Ecma TC)
concern about hard limit on guests
MM: is there a hard limit?
DT: a hard limit of 2 observers
YK: the found would require a group, I am concerned that this group would be peers on TC39. As a person who would benefit from this, I would be concerned that I would have to use scarce political resources.
DH: this could create uncomfortable situation.
YK: the flip side, such indivudals seeking funds on their own would not have this problem.
AR: TC39 or ecma may be the wrong organization, an org may exist an external group that should cover this. An example would be the jQuery foundation (or similar)
AWB: slide (Proposal)
YK: I find this unsettling
BT: MS GA rep didn't like this
WH: Google GA rep didn't like this
AWB: Adobe's GA rep did
BT: been speaking with more people at MS
AWB: other orgs are also speaking about this, such as the W3c.
AR: I am doubt it will happen in the w3c, but i feel the best solution is something similar to the jQuery foundation sponsoring this.
YK: this poltically frought process
MM: yes, we should be careful to not erode the healthy work environment
TD: A minor variant that may work, ECMA may administer the found but allow individuals to self-found.
AWB: this sounds like a legitimate expense
... tax talk ...
presenter: Yehuda Katz link to slides:
YK: the champion group has grown, in good ways.
YK: Still at stage 1, it will likely become more clear as i progress. I hope to progress it to stage 2 in munich.
YK: babel/ts want to explore some ideas before we move on.
YK: slide (quick recap)
YK: slide (on classes)
AWB: if decorators move forward, any future new class items would need to describe how to work with decorators.
YK: we should discuss, but yes we should consider this,
YK: slide (On Object literals)
YK: slide (originally out of scope)
YK: slide (prototyped in babel and TypeScript)
YK: slide (Users by angular 2 and Aurelia)
YK: class decorators are mandatory partof those frameworks
YK: slide (displays examples of angular 2 and aurelia)
YK: someone uses all the features in the proposal have some real usages, which help with features
YK: ember has also experiments, using decorators in concise object literals via an addon.
YK: react also uses this, aka @injectProps: (shows screenshot of an example) a large part of the react ecosystem seem to be excited about
YK: another example is core-decorators by jay phelps, an example of generic decorators everyone can use
MM: so what you are saying, is decorators are relieving pressure from the language to add more specific features, as they can be implemented nicely in user-land with decorators
YK: TL;DR decorators are popular
YK: slide (motivating use cases)
JM: can you state the difference of class vs constructor decorator
YK: the constructor is not a member, and my proposals do no cover it. As putting a decorator on the constructor is isomorphic to putting it on the class
YK: the main use-case for constructor replacement, is to deal with the fact that the spec says 3 sings exist. unfortunately specing this is complicated and will require additional machinery
YK: slide (changes going forward)
YK: given that there is usage now, let me describe what is important. I want to maintain rough syntactic compatibility. Angular for example, should be able to provide compatible decorators, without consumers having to change.
YK: we should decide on @ vs #, this would likely be the only user-facing change. As it would be a simple transform.
YK: slide (maintain existing capabilities for library authors)
MM: should we say rough
YK: yes, i removed 1 capability, but it appeared to not be used.
YK: slide (continuing requirements)
discussion about when decorator expressions are evaluated
WH: I noticed when reading your proposal that you allow decorators on methods defined inside object literals but not on plain properties inside object literals. Is that intentional?
YK: Not intentional. The proposal on github is old.
WH: In that case you'll get a syntax clash when you try to extend the object literal grammar to allow decorators on plain properties in addition to methods, regardless of whether you use @ or # to introduce decorators. The conflict will be between the tail of the decorator LHS expression and the property syntax that follows it.
... some discussion about jits ...
AR: We should collect evidence
YK: Some confusion, the world static confused the situation, stable would have been more work.
AR: I'm ready to believe that, but their are other things that could detect statically, that decorators impose
DH: an exampe would be, replacin an IF with a decorator, would reduce the ability to quickly analyse
YK: i accept that
AWB: is it any different then a normal predicate
DH: Abstractions cost
YK: I agree, I should not speculate
SP: In Ruby, metaprogramming can happen anywhere, at any time, and decorators are more stable
YK: you can express most metaprogramming in a visible way.
YK: slide (Continuing Requirements)
YK: We want decorators to be able to decorate everything that exists within a class, including a decorator which is generic across multiple of them
.. YK talks about how symmetry is hard, generic decorators working well has been a hard problem ...
MM: provide the decorator enough information to make these choices
MM: I don't recall the concrete API, is the decorator called with sufficient information to infer ??? ?
YK: This is the intent; we have to implement it
AWB: what is the hint then?
YK: it is a short-hand method, vs property contains a function. We have removed this from the current indication, but we have removed it.
YK: a short-hand method is the same as object literal version
AWB: super
YK: i did not realize
YK: slide (Most common reported issues)
YK: one could have a reflect.defineField that doesn't work outside of class intanstiation time.
....lots of hard to track/write up conversation, we need a stenographer....
YK continues to present read slide (Most Common reported issues)
YK: extend and decorators need to collaborate, if you could know your superclass was being subclassed a collaborating decorator would not be required.
YK: slide (Changes Max-Min)
YK: havin to feature test the object to figure this out, is unfortunate.
YK: When adding an additional descriptor, you may need access to other properties. For example, _fullName may want fullName accessor. But with private this would not work, so I proposed an abstraction that allowed reflection of the private slot. Decorating a private slot, should give access to the private slot
MM: I don't know if I agree, but we have a session later this.
YK ...diagrams something..
AWB: wouldn't it be better to have a decorator, that decorates this specifically installing the appropriate slots
MM: the exploration in private state that unified the weakMap view on how to name the private state and the slot view, was to avoid reifing the name of the private slot. To postpone the issue
YK: i dont' think that is realted
MM: the get/set functions that we are passing to the private slot..
Yk: they don't know the name
MM: the get/set functions are in a sense the reification of the name as a WeakMap
YK: ...
YK: it takes a ths
YK: that is a tracking feature of what we postponed
YK: maybe that was urgent, but I decided it is way to speculative, we can retrofit it later.
YK: i bought it up last meeting with more examples, I think it is unlikely we wont need, as it will cause grief. But we can postpone.
YK: private slots and fields will feel very similar, things that make them not compat will be a problem
MM: i understand
YK: thats all stuff i removed, I worked with ron and angular folks on a mirror based API. Which is the result of last meetings discussion. As it turns out, it is a hard to design API. I would like to propose a seperate mirror proposal, maybe at the next meeting I attend. Rather then passing in a target/name you get a mirror, with APIs that allow your to perform the required operations. The idea is to encapsolate the whole problem in a specific API.
YK: I think their are many cases were the thunks are not require, some still do. Static fields do, property fields dont.
JM: that would be a change in properties, back to what they were before
YK: Static fields are more like fields then they are like properties. People really wanted to model them the same as properties.
E: Why doesn't it work
YK: Abunch of issues, TL;DR you want to be able to say, class C, saying static singleton is class C.
DE: is their any case other then the self reference case?
YK: classes have this problem
E: this is a TDZ
YK: people don't want it to be TDZ
JM: I think mkaing static fields fields instead of properties, feels ok. I haven't found any issues.
E: isnt it already a problem?
DE: which TDZ don't you want to add
E: no fields, but the self referential inner binding gets wierd up at the end, instead of the beginning.
YK: you are correct, in one interpretation their can be a TDZ, but I would like to avoid that
YK: the timing is complicated
AWB: this is a general problem with these initializers, i think the last time we talked about it we assumed their were issues.
YK: instance initializers don't have this exact problem
E: these things will be wired up before they run
YK: there may be issues, the TL;DR static fields are fields not property
AWB: all a static field is a definition of a property on a constructor
YK: the definitiation is an instruction to install but not right now
AWB: static field name may be a property name, we will need to define the order
JM: prior we were going to evaluate them as we install them
JM: now we treat them as a description for installation
AWB: i don't think thats right
YK: i feel we will want class decorators to modify the constructor, if we do that the static properties will have been installed on the original constructor. But the static fields will be install on the wrong constructor
AWB: We have to define the ordering
AWB: a field is something that is part of a class definition, but when the instance is created the field is installed.
JM: At class definition time we will need to define the ordering
YK: this is basically the discussion that caused me to think it is not important for use to.... The timing for initializers and instantiation is all very observable. We need to be careful, as to not tie our hands to much. At the point we discover a field that may not be time it is installed
YK: many different factors, suggest specifiying static field imparatively
AWB: i believe static fields, and object literals should share the same rule
YK: i believe
AWB: it would be disturbing, if I had an object literal with two decorated properties, and a class with two static properties, and observed a different initialization order.
DH: most class systems have several phases, reality is subtle
YK: decorators interleaving with the initializer expressions.
YK: all decorators run before initializers
DH: instance initialzer expression happen at instantiation time, the whole idea of top to bottom left to right doesn't work
AWB: it doesn't work for instance stuff
DH: there is only one syntactic block
DH: there has ot be some amount of interleaving of stages
MM: something factually wrong about what you said, top -> bottom, left -> right, can be made without conflict if the instance fields and properties are set in the constructor
YK: one world view, static side is an instantion of a singleton side. You execute it as a single class, Another world view, is to embed the object literal. Both are valid and we need to decide which one
WH: the problem is, in C++ it is possible to have a static property whose initialized value is an instance of the same class. This is useful but has unexpected consequences in C++. Because they let you do that, now constexpr static value initializers cannot call static constexpr functions defined earlier in the class!
YK: What i said is true
AWB: if we don't the scoping rules get complicated
YK: it is orhogonal
YK: if it is a singleton class, that is instantiated immidately, we would run the decorators top -> bottom, followed by the initializers. Because they are seperate.
AWB: umm
YK: this should be obvious, static fields either as something as embedding an object literal in a class, or an immediate invoked class
AWB: what does it mean to embed an object literal
YK: two semantics, object assign...
AWB: we know semantically, that static fields/properties become own properties of the constructor properties
YK: both world views are consistent here
AWB: we are defining properties, so the two questions are when is the own property created on the constructor object. And when is the value computed that is the value of the property.
YK: the way classes work, there is a seperation of declaration of the class and instances
MM: we aren't talking about the instances
YK: it is impossible to explain these seperately
MM: what happen at class eval time
YK: their is a, i think many people here assume that you should not run the decorators and then the expression that is wrong. It is not my sense, and I'm trying to describe why.
YK: the only way it is observable without decorators is self reference.
AWB: this goes back to static fields
YK: I tried that, and WH said we should disallow self reference
WH: no i said, we need to clear up the ambiguity
JM provides some diagraming.
class Foo {
static someFieldA = A; <--- 1. record this; <-- 4. intiatiate
bar() { <-- 2. assign this
}
} <-- 3. end
Foo;
MM: when does Foo get bound
YK: at the end
AWB: i don't believe the spec..
MM: from within the class, if you execute a reading of the variable Foo before you get to the end of the }, you are in a TDZ
MM: the things that are creating observable side-affects are the execution of A, but the instalation of bar is not observable
YK: this is today, but decorators/blocks/computed property names etc, make this observable
AWB: computed properties are the way to bump into the TDZ today.
YK: the partially initialized class is not observed
MM: if you are executing the get of the name Foo, you get a TDZ violation
YK: i would like to avoid this
MM: im trying for a factual understanding
YK: you are correct
WH: what scope are the initializers run in
YK: current lexical
MM: they would refer to lexical names, names of properties are not lexical
AWB: elThis is really a discussion...
YK: I believe we will need to make static fields, which is why i was initially over thunking.
YK: with mirrors you don't get the actual objects
AWB: is there a concrete API
BT: there is a must discuss topic about walking down the prototype chain
YK: i have no more slides
YK: We want to avoid viewing partially iniitialized state
....
MM: we should revisit this.
YK: i just reasoned from the use-cases
YK: slide (Property decorator, v.last)
AWB: mirrors on objects, and mirrors on function definitions are quite different
MM: function definitions are not reified objects
YK: for v0 it hasn't come up
AWB: it may be relevant to constructors, you may want to see a method definition.
WH: I have the same point, if the mirror mirrors a function it can call rather than a function creation descriptor, what is the point of the mirror, why not just use the function?
YK: the open question, is a mirror the snapeshop, or a singleton object that mirrors the entity.
WH: even a snapshot is dangerous, as it could give access to mutable state.
YK: why?
WH: Shallow snapshot or deep? A shallow snapshot can point to newly created internal mutable state that the class wasn't expecting to have gotten loose yet.
SP: i believe a shallow snapshot is being described
MM: a deep snapshot is off the table
DE: trying to interrupt to switch to a different agenda item can we move this to a break out?
BT: this is relevant, but lets avoid rambling
YK: a snapshot may be wrong, if someone wants a stable reference. Which enables talking about that entity.
AWB: something is bothering me, in ECMAScript, other then modules. Have two sorts of constructs, which have complex evaluation semantics, that result in the creation of one or more objects.
It seems like fundamentally as we talk about decorators, we want to formalize those.
MM: I feel like I have learned something
AWB: i the piece I am missing, although you may have it in your head, but I would really like to 1 and 2 formalized.
YK: everything you said rings true to me, my current.. To go through the runtime semantics, I should submit this. It is reasonably clear where things go.
WH: i dont think so
YK: im not saying anyone can do this, but AWB analysis is correct
AWB: one could imagine a hook point, a processing pipeline that every class definition goes though. This could enable the extends clause aswell. This elevates the control
MM: it is a new way to think about it for me, I really like it. I have always thought about decorators as merely desugaring. But really, it is hooking the complex initialization process.
YK: yes, the motivation is to enable flexibility in the current declarative blob. I agree with the analysis. I believe it is correct to address this. We should discuss the snapshotting in a breakout. I believe having one mirror that lives the entire life.
MM: decorators thought of as multi stage programming model
YK: i think my last topic was quite long
MM: it is possible that the presentation was only understandable with this new world view.
MM: the hooking of instantiation if very distinct from multi-stage programming.
YK: yes, we should talk about this in a break out.
YK: ok, my question. I don't know how people feel about non-snapshots.
MM: Deep snapshots won't work, shallow are making a promise they can't deliver.
MM: the classic reflection APIs I am aware of are live.
MM: decorating reified things, vs multi-stage programming. Determining what the program is vs determining the value
YK: I agree, that seems fine. Im not sure what my next steps are
WH: it would be more productive if this was less vague, nothing we can carry on productively until that.
YK: that doesn't match what I need.
MM: as TC39 this isn't quite productive
WH: By more concrete, I mean a less vague proposal that we can discuss, not start implement something right away. We're not at the stage where we should be implementing yet.
DE: can you take an idea on those proposals and write it up
MM: any one of these perspectives needs to be fleshed out.
MM: fleshing out your persective is wonderful, fleshing out mutiple is also wonderful
YK: it was roughly fleshed out...
DE: I have not seen a sufficiently detailed proposal. Can you share a link
YK: i can send links, but their may be not something sufficiently speced out
MM: What is bothing me, is that as a designer you seem to be straddling multiple perspectives.
WH: the problem is, togglilng perspectives makes discussions compleciated
YK: tell me how
WH: For example, it all depends on the ordering of initialization — the different world views conflict on this.
E: isn't that the crux of the design of the whole thing the point of this
E: he is trying to figure out
YK: i am asking how to make this more conrete
MM: their are 3 distinct perspectives
These are very distinct, I would prefer to see one perspective fleshed out, this will help provide a more coherent model.
YK: I believe I am in the second camp, what leads you to believe I am not.
AWB + MM + YK will break out.
presenters: Dan Ehrenberg / Jeff Walden
JW: slide (the attack: same-origin polciy workaround)
WH: we would have more of a problem if we expanded JS syntax?
JW/DE: slide (Why not, and not earlier?)
JW: getters are more constrained, but it is slightly harder.
YK: this seems also bad
YK: can you force SW to cache the opaque thing.
JW: the browser cache is sufficient, each new script element gets invoked.
YK: throttling that seems like one way to mitigate
... some discussion to clarify the attack vectors of CSRF ...
JW: slide (The attack: Some-origin policy workdaround)
JW: Object.prototype/ Window.prototype. EventTarget.prototype
WH: Could the system say, this is not a a script?
MM: there is a header that can be used
DE: sights should use that, but that isn't sufficient.
JW: the browsers must support the flexilibty, due to far too much content depending on this.
JW: slide (...)
JHD: would [] cause the same issue wrt Array.prototype?
JW: no, not observable
JW: slide (Why not, and not earlier)
DE: i added some counters to chrome, and discovered far to many such occurances. Forcing mime-type/no-snift would break the web.
JW: slide (one solution: lock down __proto__)
AWB: ECMAScript requires that the global object had object.prototype in the chain.
JW: as of yesterday release FF ships with an immutable global object proto chain, with no compat issues so far.
JW: alpha 12 weeks, beta for 6 weeks. still no issues. (October)
YK: if you want to do this, we may explore the realm API.
JW: why?
DE: BT said they have an embedding object that uses this.
YK: you can imagine a realm API, that would allow a proxy wrapped global.
MM: wouldn't that cause the issue.
SP: no, the custom realm would not get script tags invoked with it in
YK: We should make sure that we also prevent the attacker from using realms for this, so being sure we can't get the script tag behavior in it.
JW: slide (but how?)
A. make object.prototype exotic B. add a MOP operation
MM: i've wanted option B
BT: are you ok with A. now?
MM: yes, we should explore B later.
YK: is it possible to say, it can't be a proxy?
DE: The V8 team had an idea, to prevent the global trap to be a proxy
MM: it would allow the ability to discover whether an object is a proxy or not.
... discussions. some rabbit whole ...
MM: this is fairly strong, re: web compat
YK: it is not obvious to me, as we have seen IE ship for years, and only when chrome ships do we notice the web compat issue.
DE: we will have moderate evidence by march when this freezes
DE: IE has some anti phishing technique that no one is quite sure how it works.
MM: i am in-favour of accepted ??? now
DD: I second
MM: thank you Mozilla for doing this experiment.
YK: stage 0 for function decorators?
AWB/MM: stage 0 is exploratory, make it part of the same proposal?
... discussion about splitting/decoupling proposals ...
... MH putting up slides ...
MH: first slide, method param decorators example: refresh(@lastRefreshTime timeStamp) { ... } as example
YK: additional metadata about the param they're attached to
MM: can not change meaning?
YK/MH: can change meaning. decorator gets extra info to identify that it is a function param.
MM: happy with stage 0.
MH: function param decorators: schedule(@memoize (value) => ...)
WH: Syntax conflict with the method param decorator example @leg('right') rightLeg. When used with arrow functions above, the @memoize decorator would swallow the arrow parameter list (value), just like the @leg decorator swallows ('right').
MH: corrected function param decorators example: schedule(@memoize function (value) { ... })
... discussion that clarifies that they could replace the value, like all decorators ...
MM: keep as separate stage 0 proposals
MF: tl;dr about problem trying to be solved?
MH: 1) dependency injection, example shows on constructor parameters
MH: motivation: testing (@timeout), @flaky, @disabled, @slow/@expensive, @description, @async, etc
Slides: https://docs.google.com/presentation/d/1o8jVhyVHljCFyXdxe-V4X1pUmCgx0FuFvEO0fFP4LJU/edit
MF: slides: current stage 1
MF: original goals:
MF: revised goals:
- define "portability" with Function#isPortable
- make a guarantee about the behavior of portable functions after deserialization in an equivalent lexical context
MF: what does "portable" mean slide: - a function F defined in a lexical context L is portable is any function generated from the eval of Function#toString in L has a [[Call]] that's indistinguishable from F.[[Call]]
MM: closest to "no free variables" that you want is "no free vars besides standard globals". this might allow failing on the sending side instead of the receiving side.
JHD: use case of "list the free vars" might be, user deciding if they can send a function to a webworker for example and reconstitute it safely
MM: allows description of behavior to be moved
DH: perhaps isPortable shouldn't be something we encourage people to use and we should put it not on Function.prototype
WH: Why did you define the concept of portability?
AWB: when reading the agenda, i didn't know what "isPortable" meant, nor an intuitive sense
MF: that's why i've defined it on this slide
WH: commenting on slide with definition of portability in terms of function observational indistinguishability: What does it mean to be indistinguishable? If functions A and A' both return the current time, are they indistinguishable? If A returns 5 on big-endian machines and 7 on little-endian machines and its clone A' happens to run on a different endianness from A, are they indistinguishable?
MF: ?
MF: slide (goals);
YK: some function exist, which when calling toString may not produce an evalable function.
MM: MF is addressing that, but it doesn't answer, among functions that give you an evaluable string
MF: slide (what is the lexical context?)
MF: slide (what isn't portable)
YK: does the proposal introduce isPortable false, that is evalable?
YK: isPortable means, is evaluable then.
MF: slide (what isn't portable)
MM: isPortable is things that will evaluated without a syntax error.
MF shares spec text
ARB: indistinguishablity criterion is trying to use obsrvational equivalence, which is superhard even for much simpler languages. Moreover, this requirement is impossible.
WH: Any kind of definition of isPortable like this is not sufficient to meet the indistinguishability criterion. There are plenty of places where ECMAScript gives implementations latitude in how they implement features (sort, Unicode version, and floating point library accuracy are some examples; there are many others). A deserialized copy of a function serialized on a different engine will observationally differ from its original. Given this, I still question the use for defining the concept of a portable function or isPortable.
ARB: Much simpler counterexample to indistinguishability criterion:
let g = function f() { return f === g }
Eval'ing g.toString() cannot create an indistinguishable function.
MF: already in existing spec
ARB: then it's a bug
parse tree discussion exploring the idea of replacing function equivalence with parse tree equivalence
WH: What exactly is a parse tree? What about whitespace?
DH: White space and comments should be preserved.
YK: No, they shouldn't.
... discussion about parseability, errors, new Function to detect, toSource, etc ...
MF: "possible solutions" slide