January 27th 2016 Meeting Notes
Rick Waldron
waldron.rick at gmail.com
Fri Feb 5 17:08:27 UTC 2016
January 27th 2016 Meeting Notes
Eric Farriauolo (EF), Caridy Patino (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 (LH), Nagy Hostafa (NH), Michael Saboff (MS), John Buchanan (JB),
Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar Horwat (WH), MarkS.
Miller (MM), Paul Leathers (PL), Sebastian Markbage (SM), Zibi Braniecki
(ZB), Andreas Rossberg (ARB), Ian Halliday (IH), Keith Miller (KM), Tim
Disney (TD), Misko Hevery (MH), Brad Green (BG), Kevin Smith (KS), Brad
Nelson (BN), JF Bastien (JFB), Shu-yu Guo (SYG), Rick Waldron (RW), Staś
Małolepszy (STM), Dean Tribble (DT)
## Agenda
https://github.com/tc39/agendas/blob/master/2016/01.md
## FastTrack
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 reuqests, 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?
* general consensus *
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 ecmascript262, 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 IOS 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
#### Conclusion/Resolution
- next meeting we will vote for this.
- if concerns exist, please let us know before the next meeting
## ECMA-262/402 2016 End-Game
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.
* general agreement *
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
#### Conclusion/Resolution
- 30 days before the next meeting, the final draft will be provided
- next meeting we will vote to make it ES2016
- start the out-patent review process, you may need to alert your
organizations
## Ecma archiving and web hosting issues: Github, wiki.ecmascript.org,
etc.
(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
#### Conclusion/resolution
- BT will set up reflector
- AWB will work on archival.
- AWB wil own the wiki archival process
## TC39 Invited Experts Fund - Proposal
AWB: Istvan Sebestyen floated this, this is actually Istvan's deck
AWB: root problem is as folllows, 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 ...
#### Conclusion / Resolution
----
### Decorators
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 mandetory 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 compatilbity. 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 capablity, 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 methed, 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 -> bototm, 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 happesn 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.
```js
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.
1. object literals (sorta complex)
2. class definitions (very complex)
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
1. classic OO Design Patterns book: decoration replaces value with similar
value, typically wrapper of original
2. the hooking of the instantiation process
3. mutli-stage perspective
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.
### Conclusion/Resolution
AWB + MM + YK will break out.
### Object.Prototype Security issue with Proxy
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 scrpt tag behavior in it.
JW: slide (but how?)
A. make pbject.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.
### Conclusion/Resolution
- lets do A (merge the PR now)
- TC expresses interest in B, it requires a proposal (will be stage 0 once
written)
## quick interjection: method param decorators, function expression
decorators (YK, MH)
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
#### Conclusion/Resolution
- Method param decorators at stage 0
- Function expression decorators at stage 0
## Function#toString && Function#isPortable (MF)
MF: slides: current stage 1
MF: original goals:
- remove forward-incompatible requirement
- clarify "functionally equivalent"
- standardize string representation
- clarify "actual characteristics"
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
#### Conclusion/Resolution
- none yet, will continue tomorrow morning, first thing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160205/1a085a4d/attachment-0001.html>
More information about the es-discuss
mailing list