# Nov 19 Meeting Notes
John Neumann (JN), Allen Wirfs-Brock (AWB), Yehuda Katz (YK), Eric
Ferraiuolo (EF), Erik Arvidsson (EA), Rick Hudson (RH), Matt Sweeney (MS),
Rafael Weinstein (RWS), Alex Russell (AR), Rick Waldron (RW), Dmitry
Soshnikov (DS), Jeff Morrison (JM), Sebastian Markbage (SM), Ben Newman
(BN), Reid Burke (RB), Waldemar Horwat (WH), Doug Crockford (DC), Tom Van
Custem (TVC), Mark Miller (MM)
## Welcome
JN: (Introductions)
DC: (Logistics)
JN: ...updating status of RFTG
...Adopt agenda?
Unanimous approval
JN: Approval of Sept Minutes?
Unanimous approval
## ES6 Status
AWB: (presenting Luke's spreadsheet with remaining features that need
attention)
https://skydrive.live.com/view.aspx?resid=704A682DC00D8AAD!59602app=Excelauthkey=!AAMixsO0TuyPYwc
...Function.prototype.toString still needs attention
BE: Mark is to write spec, in this case under-specify
AWB:
- Refutable pattern matching is deferred
- still need specification for enumerate / getOwnPropertyKeys/Symbols in
various places
- Proxy handlers, cut
- C-style for-let
BE: We agreed on semantics
AWB: We agreed on outer capture, but won't try to update per iteration.
Need per iteration binding.
YK: This is the consensus I recall
AWB:
- Modules, static semantics complete
- No loader/runtime semantics yet.
- Dave will have a complete spec this meeting
YK: (confirms that it's complete)
AWB: Yes, but not yet in the spec.
- Standard Modules deferred.
(TVC dials in)
## 4.4 Finalizing the Proxy API for ES6
(Presented by Tom Van Cutsem)
TVC: First three relate to es-discuss threads, re: simplifying Proxy. Jason
Orendorff expressed concerns.
- hasOwn()
- invoke()
WH:
AWB: Looked for traps for call
BE: Total traps?
AWB: Now 14 traps.
BE: Cool. Not including hasOwn()?
AWB: Not including
TVC: The next is `invoke()` trap. Leave out for now to avoid
inconsistencies with `get()`?
YK: How do you implement virtual objects? ie. an object whose `this` object
is always the proxy. Can't do it reliably without invoke.
WH: Still not reliable, even with invoke.
YK: So what are the cases?
AWB: Can still implement a virtual object or full membrane, or thin wrapper.
YK: Not the use case. Want to make an object where `this` is the proxy and
not the target.
TVC: Are you arguing that `this` should remain bound to the proxy object
upon forwarding? If yes, this is the default.
YK: As long as maintaining equivalence between `foo.bar()` and
`bar.call(foo)`
AWB: yes.
TVC: Regarding Handler API: not enough motivating use cases for proxy
handlers without community use. Propose to defer.
AWB: Let's publish the library code
TVC: It's already on github, as part of my shim. I will publish it as a
separate project to make it more accessible.
TVC: `Proxy` as a constructor? Currently, no `new` throws TypeError
AWB: Not really a class
AR: You create new ones?
AWB: No prototype
AR: Gives an instance, why not new
AWB: Would need an @@create
YK: Then shouldn't be capitalized
BE: We can do proxy
AWB: (to Tom) the concern is: if it's not new-able, should it be little-p
proxy?
TVC: Given choice between little-p proxy and requiring `new`, I prefer `new`
RW: Agree with Alex, `new Proxy()` creates new Proxies, so allow `new`
AR: Let's not duck the charge on @@create.
WH: Proxy is not a class.
YK: ...But has allocation
WH: I would hate to specify what happens when subclassing from Proxy
AWB: Must create a special constructor
TVC: @@create doesn't make sense here
BE: Is Proxy a class?
(General: no)
TVC:
DS: What is typeof and instanceof
AWB/BE: object
BE: Capital P
AWB: Ca???
DS: Whatever Proxy creates?
BE: That depends on what is created.
DS: By default?
BE: typeof depends if there is a call trap. instanceof depends on the
prototype chain. All in the spec, so can create any object (apart from
private state issues)
AWB: Ok, into the future... would value objects allow `new`?
BE: (int64 example)
...back to why should `new` throw on Proxy constructor.
BE: Seems counter intuitive: Proxy constructs objects. `int64` creates a
value. callables construct objects
[ inaudible ]
BE: these are object constructor functions, which is what people want to do
with new
AWB: this is somewhere in the middle between newing a class and a random
function that returns an object
BE: in either case, it returns a new object and proxies are factories for
object
AWB: yeah, I agree...spec currently calls them proxy factory functions
BE: pretty weird not to have new on this.. feels natural
YK: Intuitively, the difference between returning an object and not a value
AWB: we can do it...need to make it an exotic object with a special
[[Construct]]
AR: agree. Making it exotic is good.
TVC: what's the summary?
AWB: we allow new, we do it by making it exotic.
EA: Do we REQUIRE new?
WH: what does Map do without `new`?
EA: Throws
BE: Why are we requiring `new` again?
RW: Needed for subclassing
AWB: my objection is that we're trying to tell a
