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


## 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

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

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

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

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

##  Ecma archiving and web hosting issues: Github, wiki.ecmascript.org,

(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

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

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

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

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

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.

class Foo {

      static someFieldA = A; <--- 1. record this; <-- 4. intiatiate

      bar() { <-- 2. assign this
} <-- 3. end


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

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

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

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

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

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

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

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

... 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

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

## 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