May 21, 22, 23 TC39 Meeting Notes

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

May 21, 22, 23 TC39 Meeting Notes

Rick Waldron
Technical Notes (by Erik Arvidsson):
Tuesday May 21
John Neumann (JN), Allen Wirfs-Brock (AWB), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Luke Hoban (LH), Doug Crockford (DC), Yehuda Katz (YK), Brendan Eich (BE), Sam Tobin-Hochstadt (STH), Alex Russell (AR), Dave Herman (DH) (calling in), Bernd Mathiske (BM), Andreas Rossberg (ARB), Mark Miller (MM), Tom Van Cutsem (TVC), Jasvir Naga (JNA), Istvan Sebestyen (IS)



JN: Going through the agenda
Adding __proto__
Unifying iterator/generator APIs
Talking about getting user stats for test-262... 
YK: Prioritize ES6 items. So that we don’t get do ES7+ items before

Minutes approved unanimously

4.1 Object.freeze

DC: Today Object.freeze throws when primitives are passed in. Suggesting not throwing when a value type is passed in.
MM: Object.isExtensible would return false for primitives
EA: This would give an inconstint view for primitives.
AWB/YK: (In strict mode) numbers and strings lazily box so the assignment never fails.
MM: Proxies are allowed to be non extensible and throw away.
ARB: Is the suggestion to lazily wrap primitives?
MM: No, then isExtensible(7) would return true because the wrapper is extensible.
AWB: In most of the new changes we are not doing unnecessary coercion.
YK: The Chrome dev tools, console.dir(7), says “no properties” which supports treating these as empty objects.
MM: The only observable wrapper is the `this` wrapper in non strict mode.
AWB: In the new spec, Object.setPrototypeOf(7) throws.
MM: Agrees violently!

Conclusion: DC+AWB to work out the details

4.2 WeakSet

Do we need them?
MM: Trivial shim around WeakMap.
YK: Often wanted it
AWB: Adds no new capabilities.
AR: We should not limit ourselves to what is a new primitive capabilities
AI(AWB): add to spec

Consensus to add WeakSet.

4.4 Proxies


Arguments against:
- shifts the burden from spec writers/implementors to users (need to use shadow target even for non-frozen objects)
- implementors will deal with spec bugs related to invariant violations as they come up

Conclusion: Notification proxies are not approved. MM & TVC are still happy with direct proxies.


Proxy Invoke Trap and wrong |this|-binding on built-in methods

AWB: with current default behavior of “get”, “Caretaker” will break on built-ins such as Date, because the |this| binding is by default set to the proxy, so the Date built-in method will not find the correct private state.
ARB: Same issue with binary methods
...
STH: We should add invoke trap but not change the object model
MM: Pleasant to have. Separate from private state.
AWB: used to think this was an issue with proxies, but convinced that it’s an API issue: we need to provide default handlers that do the right thing, and which users can subclass. In particular, want a handler that, on forwarding, rebinds |this| to the target.
STH: If you want to proxy a Date method the underlying `this` needs to be a non wrapped Date object.
TVC: previously proposed a Handler API that defines derived traps and fundamental traps, allows you to subclass and inherit correct behavior for derived traps. Can be used as the basis.

AWB/TVC: invoke trap would make it easier to control |this|-binding
DH: Never liked breaking the semantics of [[Get]] + [[Call]]
TVC: there already exist invoke-only properties on platforms with __noSuchMethod__
AWB: For a [[Call]] it might be important to control `this` but by the time the [[Call]] is happening you do not know what `this` to use.
DH: ActionScript has a proxy and they do have an invoke trap.
BM: The most common action is to invoke a method.
? : we already gave up on the |this| invariant for accessors: in ES5, if obj.x is a getter, |this| will always be bound to obj in the getter. With proxies this is no longer true.

AI(AWB, TVC): Add spec for invoke. Tom and Allen to work out details of a Handler API that accommodates both “caretaker” (aka forwarding) and “virtual object” use cases.

Consensus: Add invoke trap.


4.11
MM: Everybody in this room wants classes and want to post pone private state to after ES6
ARB: Disagrees. 
ARB: Based on feedback, people do not want unique symbols, only private symbols.
MM: Private symbols do not work with proxies.
TVC: can still use WeakMap for private state.
DH: The most common cases where true information hiding is self hosting. The stakes are too high for the browser engines.
YK: If “iterator” would be a private symbol, you cannot create a proxy that will work with for-of loops.
ARB: Symbols (unique and private) and relations overlap.
BE: If we add symbols now we are stuck with them.
LH: Future users will be confused. They will not know what to use
BE: Unique symbol is very different from class private syntax.
AWB/MM: If we first did relationships we might not need symbols.
MM: Relationship published but not reflective.
MM: Difference between relationships and symbols: where is the mutability? This forces us to have both relationships and unique symbols.

Conclusion: ?

Report from Geneva

IS: IPR, vote on june 11, 2 docs about policy. royalty free task group should function. When approved, create royalty free group within tc39. must transition to the royalty free task group. Collect before November. Hope to make switch in 2 or 3 months.
IS: Intel submitted royalty free statement on ecma 262.
BE: So did Mozilla
IS: IPR ad hoc group, work out a solution for a software contribution from non members. IPR ad hoc group has not finished their work. 
AWB: Public RF solution? We never talked about that here.
IS: Additional channel from non members. Compromise; Fill in form on tc39 web site. Click through process. Agree RF TF. Can submit contribution through the web site.
AWB: But not the software.
IS: It is still missing. It will be the next step.
AWB: This allows someone to write up a proposal and we are allowed to read it and maybe even incorporate it.
IS: There is an ECMA recognition program. List contributors. Requests a short list of nominees.
JN: Nominees before Thursday morning.
STH: And maybe a trophy?

Item 9.1.2
JN: RFTG mode. Keep things transparent. Unanimously approved
JN: Doc 24. Any objections? Unanimously approved
4.13 Endianness of Typed array
ARB: Remember it as if we should specify this.
BE: Endianness in Typed Arrays is unspecified.
DH: Keep it open for now... Same system to same system. Using data view, which is explicit, there is no problem.
STH: We don’t know what WiiU will do?
AWB: Or they decide not to comply to the spec
DH: WebGL is endian agnostic.

Conclusion: Leaving it unspecified in ES6.

4.18 __proto__

STH: Recollection, first as data property, then as an accessor. Then discussed the power of that setter. Set the [[Prototype]] in the [[Realm]]. Then Allen wrote the spec. Realized that there were some problems with that design. Roughly the same power as Object.setPrototypeOf.
MM: Existence of a setter... as long as we have the extensibility restriction, that is sufficient.
AWB: Why restrict __proto__ and not other
DH: Objects belonging to a realm is a bad idea.
MM: No more reason to restrict the setter.
STH: Bind __proto__ setter to the object upon extraction
MM: In SES objects that are non extensible. Not going to remove __proto__ going forward.
ARB: If Object.prototype.__proto__ is a data property, making it non writable prevents other objects to use assign to set __proto__.
AWB: If Object.prototype.__proto__ is an accessor that just calls Object.{set,get}PrototypeOf.
AR: Best practice on the web is important even in the future.
TVC: If we have O.p.__proto__ do we want Object.setPrototypeOf or just Reflect.setPrototypeOf?
AWB: Makes sense to have Object.setPrototypeOf for consistency.
EA: Where do we draw the line (Object.x or Reflect.x)?
DH: People will need to be able to get this before we have a reflect module.
TVC: We need both because they have different return value (reflect setPrototypeOf returns boolean success value).

Conclusion: __proto__ is an accessor on Object.prototype. The setter mutates [[Prototype]]. There is no “poison pill”. We will provide both Object.setPrototypeOf and std:reflect setPrototypeOf.


Naming of @@iterator
AWB: Suffix with $
STH: Opposed to special naming. People don’t do this kind of naming convention. Why do we want to introduce this concept?

class Foo {
  *[iterator]() {
    yield ...
  }
}

Conclusion: No special naming

Generators and iterators
AWB: send is gone in favor of next(arg) (only first arg is passed through in yield*)
YK: Whether generators return a frozen object or not?
BE: close is gone


 
Wednesday May 22 2013
John Neumann (JN), Allen Wirfs-Brock (AWB), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Luke Hoban (LH), Doug Crockford (DC), Yehuda Katz (YK), Brendan Eich (BE), Sam Tobin-Hochstadt (STH), Alex Russell (AR), Dave Herman (DH) (calling in), Bernd Mathiske (BM), Andreas Rossberg (ARB), Mark Miller (MM), Tom Van Cutsem (TVC), Istvan Sebestyen (IS), Jasvir Naga (JNA)


4.16 Spec update


YK: ToPositiveInteger is needed by JSIDL
AI(YK+AWB): Put an algorithm in the spec that DOM can use so that we get the same behavior in JS and DOM.

6 General implementation experiences

ARB: We started implementing generators but things are pretty smooth. 
BE: Doing modules at the moment.
AWB: Bunch of bug fixes in the spec related to classes.

4.9 String templates

MM: Suggests status quo.
AR: Objects.
MM: Controversy related to tag-less templates. Alternatives include making tag-less templates an error, delayed evaluation (contextually provided)
AR: Econics: naked interpolation is too attractive. Should always have a tag to encourage users to think about which behavior is correct.
YK: I cannot support Alex’s proposal.
STH: What would the name of this tag be?
AR: Something that is imported from a module.
STH: Concerned about short names and conflicts.
YK: People will just use ‘s’ without thinking.
YK: People should use HTML templating engines.
DC: Alex’s testimony about application developer feedback is relevant.
LH: it sounded like Google engineers were using a template system
EA: Correct.
MM: Does anyone prefer taking out TS if they don’t get tag-less TS?
Everyone: Agrees that it is better to require tag to remove TS from ES6.
AR: Strings are always used later in some context. Communicating the intent
AWB: String concat vs string interpolation have the same issue.
LH: Assumes that maybe only 20% of the uses ot TS are susceptible to XSS
MM: Removing tag-less does not reduce XSS because people will just use s`. TS helps people transition to a better world. Once they have have a TS it will be easy to add  an html tag at the front as needed.
ST: It will be painful to import String raw and alias that to s.
MM: Maybe put tag-less in appendix?  Withdrawn idea because no one likes it.
YK: You should not have use string based APIs.
AR: Willing to abstain but “Y’all are making a big mess”
BM: Half convinced by Alex.
LH: Different code bases will use different tags for normal string interpolation so moving between code bases will be hard to.
AR: That is a good thing. Forces people to think.
MM: Template strings in E. 
STH: Lots of contexts where XSS is not an issue.
BM: More ways to XSS is a bad thing.
BE: if people have to import s then the economics change and people will stick to +

Conclusion: AR and BM sustains. We continue with the status quo (tag-less ts is supported)

JSON

DC: IETF wants to change JSON
MM: The 2 documents should have exactly the same text except for boilerplate.
IS: Should it be done in TC39?
DC: Most of the work will be on the mailing lists
AWB: Who will be the editor?
DC: Hopes they (IETF) will provide an editor.
JN: Should this be fast tracked to ISO?
DC: That makes sense.
JN: How long do you expect this to take?
DC: Has taken a long time to coordinate and get started.
DC: 5.1 specs the 2 functions that uses the JSON format.

4.10 Modules

STH: Progress since last meeting. Discuss “module naming”, “naming standard modules”.
STH: Wiki is up to date with the current proposal. Spec is “wiki complete”. Jason Orendorff of Mozilla has worked on flushing out semantic issues. Moz is implementinb parsing of modules.
STH: Syntax: Made a couple of changes.
A. To support anonymous exports

  export default expr;

  import $ from ‘jquery’;  // imports default anonymous export

If there is no default then the above is an error

  import {ajax} from ‘jquery’;

  import {ajax as A} from ‘query’;

to reduce confusion and to make it clear that this is not destructuring.

  module fs from ‘js/fs’

fs is a module instance object

The following is not valid:

  import {...} from fs;  // SyntaxError

Renaming on export:

  let foo = 13;
  export {foo as bar};
  export {foo};

The following is not valid:

  export foo;

STH: The only evaluation here is “13”. The rest are just bindings that are shared with the outside/module importer.
MM: Bad idea to allow external modules to assign to imports.
DH: Imported bindings are read only to the importer.
AWB: This is new semantics to the language. Is there a list of these new semantics modules introduce?
AWB: Is there a way to get the default export from the instance module obejct.
STH: There will be a well known symbol name to get to it.
AWB: Does module instance objects inherit from Object.prototype.
DH: No. Because we do not want any pollution.
JNA: Is it an error to assign to an imported binding?

  import {ajax} from ‘jquery’;
  ajax = 14;  // Error

AR: What is the reason for not extending Object.prototype or some other object?
YK: To prevent people from expecting toString to be there (???)
DH: fs.readFile We don’t want to statically check this deeply inside an expression.

  fs.toString

THS: The plan is to allow the above to be a static error in the future.
DH: To keep things clean.
AWB: Concerned about the dot operator
ARB: Don’t want less checking if you do not use import.
DH: Do not want refactoring hazards.
ARB: This only affect the static semantics.
AWB: Can you use square bracket?
STH: Square bracket is dynamic.
AR: This is only a static check that is lost. At runtime there will still be errors.
LH: Concerned about default export. Now people will have to decide which approach to use.
STH: This is already the case in Node.js today.
LH: Today you might get any object, it might be callable with properties.

  var fs = require(‘fs’);  // module instance
  var glob = require(‘glob’);  // function with properties
  var parse = require(‘parse’);  // function

  module fs from ‘fs’;
  import glob from ‘glob’;
  import {sync} from ‘glob’;
  import parse from ‘parse’;

Lots of discussion...

  import {sync} from ‘glob’;

_alt_
  import glob from ‘glob’;
  var {sync} = glob;
  import {ajax} from ‘jquery’;

LH: Prefers “export =” and lose static checking when people opt in to single anonymous export.
STH/YK: We already agreed that we want static checking.
LH: Even for new things being built, this is causing a confusion.
AWB: It is unclear when and what you want to export as the default export.
BM: Wants

  import default $ from ‘jquery’

to ensure that people have to be explicit about what they import.
DH: This is just syntax and we are wasting time “bikeshedding”
AWB: What is the best practice? Is there a single module containing Map, Set & WeakMap or...
YK: WeakMap should be its own import:

  import WeakMap from ‘collections/WeakMap’;

BE: We have to pay attention to what Node/AMD do today.
YK: AMD tries to make modules small to reduced byte size of the dependencies.

STH: And now to semantics
STH: Major things that changed. Use options object more consistently.
STH: The wiki page is up to date.
STH: Need to decide whether the browser loader is in the appendix or if it is in some w3c spec. Want core language semantics to treat the names as strings, not the semantics of these strings.
STH: Bulk loading. One HTTP request to load multiple modules. Possible to implement. Create fecth hook. Stores module notations in a side table. In the xhr response, split the result and call the different fulfill hooks.
EF: Sounds like what we do today in YUI loaders.
EF: How would you write the HTML?
DH: Initial script tag with configuration. Second script tag as usual. Alt 2 is to have configuration and dynamic module load in the same script block.

  <script>
  ondemand
  </script>
  <script src=”main.js” async></script>

alt 2

  <script>
  ondemand
  System.require(“main.js”, function() { …. });
  </script>
DH: script[async] today have to use an external src.

STH: Naming and declarations of modules.
ARB: Presenting slides...
AWB: The rate that internal vs external names changes is very different.
STH:

  module ‘m’ { … }
  module ‘n’ {
    import x from ‘m’;
    …  // this part is not executed.
  }
  import x from ‘m’;

STH: Configuration step is mostly about other people’s code.
….

  <script>
  module ‘m’ { … }
  module ‘n’ {
    import m from ‘m’;
    function f() {
      Loader.eval(“import m from ‘m’”);
    }
  }
  </script>

m is fixed at compile time

ARB: Not opposed to logical modules. Wants both lexical and logical
DH: Not opposed to lexical modules. 
YK: Too late to work out lexical modules for ES6.
ARB: If we wait we will have redundancy.
YK: Want declarative form to be able to prefetch etc.
BE: I want lexical modules (in the future) but logical modules are easier to use.
ARB: Since I don’t seem to be able to convince anyone I’m going to drop this
ARB: For the record. Major concern about the global registry becoming the new global object.

Conclusion: Move along with Dave and Sam’s proposal. Work on lexical modules for ES7


Promises vs Monads

MM: Presenting...

 
Thursday May 23 2013
John Neumann (JN), Allen Wirfs-Brock (AWB), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Luke Hoban (LH), Doug Crockford (DC), Yehuda Katz (YK), Sam Tobin-Hochstadt (STH), Alex Russell (AR), Dave Herman (DH) (calling in), Bernd Mathiske (BM), Andreas Rossberg (ARB), Mark Miller (MM), Tom Van Cutsem (TVC), Istvan Sebestyen (IS)

Promises vs Monads

MM: Continuing from yesterday

STH: Don’t like resolve but not willing to die on this hill.
AR: DOM has a bunch of ad hocs APIs to do promise like things.
YK: Mozilla is also actively working on APIs using promises.
AR: A lot of methods today return void so we can change these to return a promise. This is forward compatible.
AR: then does recursive unwrapping
...

Next Meetings

July 23 - 25 @ Microsoft, Redmond
Sept 17 - 19 @ Bocoup, Boston
Nov 19 - 21 @ PayPal, San Jose

ES6, ES7, ES8... Mark’s Strawman Roadmap

LH: The important part is not the features but the process.
AWB: Can things be decoupled?
LH: These kind of structural questions are the important part
MM: Suggests “currency” to be the main theme.
AWB: Thought about the event loop. All we need is a processing queue... put things in the front and the back.
DH: Only need to add to the back.
AWB: OK.
STH: The callback is called at some later point.
AR: Don’t think we need to specify the order.
STH: If we are going to specify promises etc we need to be able to specify things in detail. We can be loose in ES6 and then come back in ES7 and provide a more tight spec.
DH: We could specify the pending events as a set or something. 
DH: Not sure if there is a consensus that we want a fast small ES7. Not opposed to a modularized approach.
AR: Are there any browsers that are not shipping stable ES6 features today.
YK: Yes. V8.
AWB: Where we have problem today is that there is a lot of interdependency.
MM: These (“concurrency”) are coupled together to the event loop
AWB: We can do it as a separate non 262 spec
DH: Opposed to a separate spec. Introduces versioning confusion.
AWB: Roll up
DH: Think of all the extra overhead.
STH: Big difference with 402 since it was run by different people.
LH: Lack of confidence in new features has been an issue for implementers. Good exceptions were Object.observe and Proxies where the wiki contained a mostly complete spec.
AWB: We need to have wiki proposals be deltas to the spec.
TVC: We could have “stable” wiki pages. These would have complete spec deltas.
DH: Very concerned about over modularizing.
AWB: We need to find a way to work faster and be less monolithic.
DH: Agree. ES6 process has blocked implementation work.
LH: We are not committed to our designs.
STH: We are not resolving issues until we start to spec. We are not getting feedback until engines starts to implement.
EA: The problem is that we didn’t start to spec things until very late. We had agreements on features long before there was any spec drafts for them.
YK: More from our champions before we get to concensus.
ARB: Lots of the proposals were very vague.
AWB: The more complete spec you bring to tc39 the better chance you have to reach consensus.
ARB: Lack of early spec leads to lack of early implementations...
AWB: ...which leads to lack of feedback.
LH: Not more work, just doing the work earlier before things pile up too much.
DH: Need to look at the dependency graph. Hold of the work of later feature.
ARB: We need to higher bar before we accept proposals.
MM: What we agreed to 2 years ago was that the features are the one we want to spend work on speccing.
LH: Less features to bite of.
DH: A lot of us have a hard time not getting too engage in too many features.
YK: if we focused more effort on managing the overall complexity instead of getting stuck on a lot of technical discussions (and nit picking).
DH: Object.observe and Proxy moved fast but are fairly isolated features
TVC: Didn’t involve syntax.
AWB: With ES6 we had a long backlog.
DH: A language will have smaller and smaller complexity budgets as it grows.
AR: ES future needs events
DH: Since this is Mark’s wishlist people will throw in their pet features.
MM: This is the direction I am going to work.
LH: There is a page on the wiki outlining the goals.
LH: Looking for 2 things: Something that would allow earlier implementations. Have not brought proposals (over the last 2 years) because we have been blocked by ES6.
LH: When is the appropriate time to bring new proposals to TC39?
AWB: We are free to do what we want. We can issue 6.1, 6.2 etc or technical reports which would serve as a recommendation.
DH: We cannot exclusively work on ES6.
YK: Time at f2f is the most important. Champions can go off and do what they want.
DH: Suggests adding non ES6 items to the agenda. We will prioritize the non es6 stuff we can get to given our limited time.
YK: We should reinstate the rule that agenda items needs links to wiki pages.
YK: Spec language is good but examples at the top are a must.
ARB: Add step after proposal. For example “stable” or “spec” which a proposal gets promoted to once there is a spec draft, good enough to start implementing.
DH: Strawman: Anything goes. 
YK: Proposals used to mean approved.
DH: 3 sections: strawman, proposal, spec/candidate. Keep strawman. Work on improving as a proposal, and when mature enough promoted to next level.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Dmitry Soshnikov

On Jun 2, 2013, at 9:46 AM, Rick Waldron wrote:


4.10 Modules

STH: Progress since last meeting. Discuss “module naming”, “naming standard modules”.
STH: Wiki is up to date with the current proposal. Spec is “wiki complete”. Jason Orendorff of Mozilla has worked on flushing out semantic issues. Moz is implementinb parsing of modules.
STH: Syntax: Made a couple of changes.
A. To support anonymous exports

  export default expr;

  import $ from ‘jquery’;  // imports default anonymous export


I missed that, and current wiki draft doesn't explain it either, but -- what was a rationale of using string literals on imports, and, worth, also for module names at define?

I could assume this for runtime variable module names (different strings in a var) to import different modules based on condition, but I don't think it's the reason and that it's even possible.

If it's for namespacing, can the namespaced names be parsed w/o quotes (seems they can)? And even if they cannot, why make the ugly strings for simple, non-namespaced, module names too? For consistency?

Can only the namespaced and external modules be wrapped into quotes?

P.S.:

Also this repetition seems weird to do every time:

module DOMMunger from 'DOMMunger';

import even from 'Even';

Both can be just

import DOMMunger;
import Even;

If the "single default expression" is present, it's the value of import, otherwise it's the module object. 

Dmitry

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Tab Atkins Jr.
In reply to this post by Rick Waldron
On Mon, Jun 3, 2013 at 1:46 AM, Rick Waldron <[hidden email]> wrote:

> Promises vs Monads
>
> MM: Presenting...
>
>
> Thursday May 23 2013
> John Neumann (JN), Allen Wirfs-Brock (AWB), Eric Ferraiuolo (EF), Erik
> Arvidsson (EA), Luke Hoban (LH), Doug Crockford (DC), Yehuda Katz (YK), Sam
> Tobin-Hochstadt (STH), Alex Russell (AR), Dave Herman (DH) (calling in),
> Bernd Mathiske (BM), Andreas Rossberg (ARB), Mark Miller (MM), Tom Van
> Cutsem (TVC), Istvan Sebestyen (IS)
>
> Promises vs Monads
>
> MM: Continuing from yesterday
>
> AR: https://github.com/slightlyoff/Futures/blob/master/Promise.idl
> STH: Don’t like resolve but not willing to die on this hill.
> AR: DOM has a bunch of ad hocs APIs to do promise like things.
> YK: Mozilla is also actively working on APIs using promises.
> AR: A lot of methods today return void so we can change these to return a
> promise. This is forward compatible.
> AR: then does recursive unwrapping

I can't tell what, if anything, was concluded from this.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Sam Tobin-Hochstadt
On Sun, Jun 2, 2013 at 4:44 PM, Tab Atkins Jr. <[hidden email]> wrote:

>
>> Promises vs Monads
>>
>> MM: Continuing from yesterday
>>
>> AR: https://github.com/slightlyoff/Futures/blob/master/Promise.idl
>> STH: Don’t like resolve but not willing to die on this hill.
>> AR: DOM has a bunch of ad hocs APIs to do promise like things.
>> YK: Mozilla is also actively working on APIs using promises.
>> AR: A lot of methods today return void so we can change these to return a
>> promise. This is forward compatible.
>> AR: then does recursive unwrapping
>
> I can't tell what, if anything, was concluded from this.

This is the discussion that I summarized here:
http://esdiscuss.org/topic/theparadoxofpartialparametricity#content-28

The short summary is that Mark's "AP3" had rough consensus in the room.

Sam
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Tom Van Cutsem-3
In reply to this post by Rick Waldron
2013/6/2 Rick Waldron <[hidden email]>
4.4 Proxies


Arguments against:
- shifts the burden from spec writers/implementors to users (need to use shadow target even for non-frozen objects)
- implementors will deal with spec bugs related to invariant violations as they come up

Conclusion: Notification proxies are not approved. MM & TVC are still happy with direct proxies.

For those interested in more background info on this item, see my post:

Cheers,
Tom

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Andreas Rossberg-4
In reply to this post by Dmitry Soshnikov
On 2 June 2013 22:19, Dmitry Soshnikov <[hidden email]> wrote:

>> 4.10 Modules
>>
>> STH: Progress since last meeting. Discuss “module naming”, “naming standard
>> modules”.
>> STH: http://wiki.ecmascript.org/doku.php?id=harmony:modules
>> STH: Wiki is up to date with the current proposal. Spec is “wiki complete”.
>> Jason Orendorff of Mozilla has worked on flushing out semantic issues. Moz
>> is implementinb parsing of modules.
>> STH: Syntax: Made a couple of changes.
>> A. To support anonymous exports
>>
>>   export default expr;
>>
>>   import $ from ‘jquery’;  // imports default anonymous export
>
> I missed that, and current wiki draft doesn't explain it either, but -- what
> was a rationale of using string literals on imports, and, worth, also for
> module names at define?

Modules won't have lexical scope, they will just be named by (more or
less) arbitrary strings in a single (per-loader) global name space.
That was a change made last November, and some of us (well, me, in
particular) have disagreed with it ever since. You can read up on most
of the pro & con arguments in the recent monster thread starting here:

https://mail.mozilla.org/pipermail/es-discuss/2013-April/030165.html

FWIW, I still think this is a fundamental mistake, but it is now
pretty much set in stone. Hopefully, we'll get proper lexical scoping
in ES7.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Yehuda Katz
On Mon, Jun 3, 2013 at 2:02 AM, Andreas Rossberg <[hidden email]> wrote:
On 2 June 2013 22:19, Dmitry Soshnikov <[hidden email]> wrote:
>> 4.10 Modules
>>
>> STH: Progress since last meeting. Discuss “module naming”, “naming standard
>> modules”.
>> STH: http://wiki.ecmascript.org/doku.php?id=harmony:modules
>> STH: Wiki is up to date with the current proposal. Spec is “wiki complete”.
>> Jason Orendorff of Mozilla has worked on flushing out semantic issues. Moz
>> is implementinb parsing of modules.
>> STH: Syntax: Made a couple of changes.
>> A. To support anonymous exports
>>
>>   export default expr;
>>
>>   import $ from ‘jquery’;  // imports default anonymous export
>
> I missed that, and current wiki draft doesn't explain it either, but -- what
> was a rationale of using string literals on imports, and, worth, also for
> module names at define?

Modules won't have lexical scope, they will just be named by (more or
less) arbitrary strings in a single (per-loader) global name space.
That was a change made last November, and some of us (well, me, in
particular) have disagreed with it ever since. You can read up on most
of the pro & con arguments in the recent monster thread starting here:

https://mail.mozilla.org/pipermail/es-discuss/2013-April/030165.html

FWIW, I still think this is a fundamental mistake, but it is now
pretty much set in stone. Hopefully, we'll get proper lexical scoping
in ES7.

I'm personally in favor of getting lexical scope in ES7, and retrofitting the current module declarations so that they desugar into the creation of a lexical module and a declarative registration of that module in the registry.

```
module "foo" {

}

// would be equivalent to something like

module <gensym> {

}

export module <gensym> as "foo";
```

We discussed this briefly at the last meeting on a whiteboard. It requires some more thought, and I'd love to have you help work on something like this for ES7.

I'm glad that we came to a (grudging) consensus on moving forward with the current ES6 proposal for ES6, with a clear idea on where to start for ES7.


/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Brendan Eich-3
Yehuda Katz wrote:

> On Mon, Jun 3, 2013 at 2:02 AM, Andreas Rossberg <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 2 June 2013 22:19, Dmitry Soshnikov <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >> 4.10 Modules
>     >>
>     >> STH: Progress since last meeting. Discuss “module naming”,
>     “naming standard
>     >> modules”.
>     >> STH: http://wiki.ecmascript.org/doku.php?id=harmony:modules
>     >> STH: Wiki is up to date with the current proposal. Spec is
>     “wiki complete”.
>     >> Jason Orendorff of Mozilla has worked on flushing out semantic
>     issues. Moz
>     >> is implementinb parsing of modules.
>     >> STH: Syntax: Made a couple of changes.
>     >> A. To support anonymous exports
>     >>
>     >>   export default expr;
>     >>
>     >>   import $ from ‘jquery’;  // imports default anonymous export
>     >
>     > I missed that, and current wiki draft doesn't explain it either,
>     but -- what
>     > was a rationale of using string literals on imports, and, worth,
>     also for
>     > module names at define?
>
>     Modules won't have lexical scope, they will just be named by (more or
>     less) arbitrary strings in a single (per-loader) global name space.
>     That was a change made last November, and some of us (well, me, in
>     particular) have disagreed with it ever since. You can read up on most
>     of the pro & con arguments in the recent monster thread starting here:
>
>     https://mail.mozilla.org/pipermail/es-discuss/2013-April/030165.html
>
>     FWIW, I still think this is a fundamental mistake, but it is now
>     pretty much set in stone. Hopefully, we'll get proper lexical scoping
>     in ES7.
>
>
> I'm personally in favor of getting lexical scope in ES7, and
> retrofitting the current module declarations so that they desugar into
> the creation of a lexical module and a declarative registration of
> that module in the registry.
>
> ```
> module "foo" {
>
> }
>
> // would be equivalent to something like
>
> module <gensym> {
>
> }
>
> export module <gensym> as "foo";
> ```
>
> We discussed this briefly at the last meeting on a whiteboard. It
> requires some more thought, and I'd love to have you help work on
> something like this for ES7.
>
> I'm glad that we came to a (grudging) consensus on moving forward with
> the current ES6 proposal for ES6, with a clear idea on where to start
> for ES7.

Me too. And for the record, I made a point (this was the second day,
which was the last day of the three-day meeting that I could attend) as
I was heading out: this "desugaring" or something like it shows that the
ES6 syntax to declare-and-register at once, via

module "foo" {
   ...
}

is important to do first or at the same time, because any equivalent
longer form is simply user-hostile in comparison.

I recall Andreas conceding this point, but I could have misinterpreted him.

If the concern is that the desugaring can't work, we can work through it
in parallel with ES6 spec finalization and prototype implementations.
But the short form is winning because short in the DRY sense. That's the
whole point.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Dmitry Soshnikov
In reply to this post by Andreas Rossberg-4
I see. Yeah.. it looks at least weird (even if not lexical, which, yeah -- bad, why still ugly string names?), and I agree it could lead to a fundamental mistake since will stick for years until ES7.

Thanks for the original thread, will take a detailed look, but from the first pass it seems I agree with what you're saying there.

Dmitry


On Mon, Jun 3, 2013 at 2:02 AM, Andreas Rossberg <[hidden email]> wrote:
On 2 June 2013 22:19, Dmitry Soshnikov <[hidden email]> wrote:
>> 4.10 Modules
>>
>> STH: Progress since last meeting. Discuss “module naming”, “naming standard
>> modules”.
>> STH: http://wiki.ecmascript.org/doku.php?id=harmony:modules
>> STH: Wiki is up to date with the current proposal. Spec is “wiki complete”.
>> Jason Orendorff of Mozilla has worked on flushing out semantic issues. Moz
>> is implementinb parsing of modules.
>> STH: Syntax: Made a couple of changes.
>> A. To support anonymous exports
>>
>>   export default expr;
>>
>>   import $ from ‘jquery’;  // imports default anonymous export
>
> I missed that, and current wiki draft doesn't explain it either, but -- what
> was a rationale of using string literals on imports, and, worth, also for
> module names at define?

Modules won't have lexical scope, they will just be named by (more or
less) arbitrary strings in a single (per-loader) global name space.
That was a change made last November, and some of us (well, me, in
particular) have disagreed with it ever since. You can read up on most
of the pro & con arguments in the recent monster thread starting here:

https://mail.mozilla.org/pipermail/es-discuss/2013-April/030165.html

FWIW, I still think this is a fundamental mistake, but it is now
pretty much set in stone. Hopefully, we'll get proper lexical scoping
in ES7.

/Andreas


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Brendan Eich-3
Dmitry Soshnikov wrote:
> I see. Yeah.. it looks at least weird (even if not lexical, which,
> yeah -- bad, why still ugly string names?), and I agree it could lead
> to a fundamental mistake since will stick for years until ES7.

The fundamental mistake would be rejecting the detailed rationale for
ES6 modules, in favor of something more verbose and error prone.

Lexical modules can be added, but deferring them does not mean the
current design is "fatally flawed". "Incomplete" I could see, not
"fatally flawed".

And arguing for *only* lexical modules and *requiring* people to
register them manually after declaring them, one by one, is a
user-hostile move that TC39 will not agree to.

So you're left arguing "incomplete", at best.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Andreas Rossberg-4
On 4 June 2013 00:31, Brendan Eich <[hidden email]> wrote:

> Dmitry Soshnikov wrote:
>>
>> I see. Yeah.. it looks at least weird (even if not lexical, which, yeah --
>> bad, why still ugly string names?), and I agree it could lead to a
>> fundamental mistake since will stick for years until ES7.
>
> The fundamental mistake would be rejecting the detailed rationale for ES6
> modules, in favor of something more verbose and error prone.
>
> Lexical modules can be added, but deferring them does not mean the current
> design is "fatally flawed". "Incomplete" I could see, not "fatally flawed".
>
> And arguing for *only* lexical modules and *requiring* people to register
> them manually after declaring them, one by one, is a user-hostile move that
> TC39 will not agree to.
>
> So you're left arguing "incomplete", at best.

Yeah, from my point of view, this argument is based on entirely the
wrong premise, namely that manually providing registration names is
both common and good practice. Looking at require.js or node, the
opposite is true: not only do people _not_ normally write named module
definitions, they are in fact explicitly _discouraged_ from doing so.
The recommended practice is to put modules in files and have named
module definitions only as the result of invoking a _tool_, like the
optimizer of require.js.

The natural syntax of ES6 module declarations, on the other hand, will
probably _encourage_ people to use these declarations, and make them
believe that they are the best way to structure application. If you
ask me, that's a fundamental flaw. The only places where you really
want to manually use explicit module declarations is for local
modules, and those are exactly the cases where you really want lexical
naming and no global namespace pollution.

That said, there clearly needs to be a way for tools (and humans, if
they desire) to create module bundles and register the modules defined
in those. But designing the whole language around an optimized syntax
for the latter and compromising good PL principles for it still seems
backwards to me. And yes, fundamentally flawed. (Not sure anybody said
"fatal".)

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Kevin Smith
I cannot agree with Andreas more.  In my opinion, module registrations should not be used as an authoring format, but only as a target for tooling (specifically multiplexers).

In any case, I don't see how there is _true_ consensus around this issue at this time, nor do I see that anything is set in stone quite yet.  In my view, the only thing holding us back is the lack of lexical modules.  It appears to me that:

- Everyone involved wants lexical modules at _some_ point
- There are some participants that consider the lack of lexical modules a "fundamental flaw".
- The semantics of lexical modules are not really in dispute

I have created an initial implementation of a package bundler using lexical modules here:


An example output of the tool is here:


I could fairly easily change the tool so that it uses global registrations, instead of lexical modules.  I'd have to use arbitrary random strings as module names to minimize the chance of collision with some other valid file, but it's possible.  But note: 

Using global module registrations for bundling means that it is not possible to hide internal modules from external clients!

I consider the inability to create high integrity packages to be a fundamental flaw.  The simple addition of lexical modules to the current design will correct this flaw.

{ Kevin }

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Sam Tobin-Hochstadt
On Tue, Jun 4, 2013 at 9:22 AM, Kevin Smith <[hidden email]> wrote:
> - The semantics of lexical modules are not really in dispute

This is not correct. Andreas, Dave, and I spend a lot of time working
on the semantics of lexical modules, and there are significant
difficulties.  If you get rid of recursion, and if modules cannot be
exported from other modules, and then imported from, then things are
easier, but I don't think that's what we want.

Sam
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Kevin Smith


This is not correct. Andreas, Dave, and I spend a lot of time working
on the semantics of lexical modules, and there are significant
difficulties.  If you get rid of recursion, and if modules cannot be
exported from other modules, and then imported from, then things are
easier, but I don't think that's what we want.


I was not aware of this, and it's good to know.  Perhaps working through these difficulties now would be a good idea.

Thanks, Sam.

{ Kevin }

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Andreas Rossberg-4
In reply to this post by Sam Tobin-Hochstadt
On 4 June 2013 15:31, Sam Tobin-Hochstadt <[hidden email]> wrote:
> On Tue, Jun 4, 2013 at 9:22 AM, Kevin Smith <[hidden email]> wrote:
>> - The semantics of lexical modules are not really in dispute
>
> This is not correct. Andreas, Dave, and I spend a lot of time working
> on the semantics of lexical modules, and there are significant
> difficulties.  If you get rid of recursion, and if modules cannot be
> exported from other modules, and then imported from, then things are
> easier, but I don't think that's what we want.

I think you are somewhat overstating the difficulties. The only real
problem was in the intersection of "include *" and nested modules and
recursion. We now have neither of the former two, so the problem
wouldn't arise as things stand now. Even adding nested modules would
not pose a problem (although it would make the static semantics
somewhat more complicated).

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Sam Tobin-Hochstadt
On Tue, Jun 4, 2013 at 9:45 AM, Andreas Rossberg <[hidden email]> wrote:

> On 4 June 2013 15:31, Sam Tobin-Hochstadt <[hidden email]> wrote:
>> On Tue, Jun 4, 2013 at 9:22 AM, Kevin Smith <[hidden email]> wrote:
>>> - The semantics of lexical modules are not really in dispute
>>
>> This is not correct. Andreas, Dave, and I spend a lot of time working
>> on the semantics of lexical modules, and there are significant
>> difficulties.  If you get rid of recursion, and if modules cannot be
>> exported from other modules, and then imported from, then things are
>> easier, but I don't think that's what we want.
>
> I think you are somewhat overstating the difficulties. The only real
> problem was in the intersection of "include *" and nested modules and
> recursion. We now have neither of the former two, so the problem
> wouldn't arise as things stand now. Even adding nested modules would
> not pose a problem (although it would make the static semantics
> somewhat more complicated).

Well, it's unclear to me exactly what semantics Kevin was proposing,
but the current system has "export * from ..." and this introduces
many of the same problems once you import and export modules.

And the complexity of the static semantics is what I'm trying to point
out, fundamentally.

Sam
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Kevin Smith


Well, it's unclear to me exactly what semantics Kevin was proposing,
but the current system has "export * from ..." and this introduces
many of the same problems once you import and export modules.

And the complexity of the static semantics is what I'm trying to point
out, fundamentally.


We need nested modules, but I'm thinking that we would be okay disallowing the exporting of modules in the first pass.  If modules cannot be exported (and hence imported), are there still problems (with complexity or otherwise)?

I'm still trying to get a handle on the problem or complexity which arises when adding the ability to export modules.  Is there a way that we can state the problem in terms of an algorithm (graph traversal, etc)?

{ Kevin }

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May 21, 22, 23 TC39 Meeting Notes

Andreas Rossberg-4
On 4 June 2013 16:19, Kevin Smith <[hidden email]> wrote:

>
>>
>> Well, it's unclear to me exactly what semantics Kevin was proposing,
>> but the current system has "export * from ..." and this introduces
>> many of the same problems once you import and export modules.
>>
>> And the complexity of the static semantics is what I'm trying to point
>> out, fundamentally.
>
> We need nested modules, but I'm thinking that we would be okay disallowing
> the exporting of modules in the first pass.  If modules cannot be exported
> (and hence imported), are there still problems (with complexity or
> otherwise)?
>
> I'm still trying to get a handle on the problem or complexity which arises
> when adding the ability to export modules.  Is there a way that we can state
> the problem in terms of an algorithm (graph traversal, etc)?

With nesting the dependency graph between modules gets a second kind
of edge, because you then have dependencies of the kind 'imports-from'
as well as 'contains/exports'. And that introduces new potential for
cyclic dependencies.

But overall, it does not matter much. You can have cycles anyway, and
as long as every import-export edge has an explicit annotation about
what is imported (which is the case unless you add "import *"), so
that all scoping is apparent, you can always check all constraints by
two linear passes over the module structure that first collects
expected export sets and second validates them. By using a constraint-
or unification-based approach, you can do it in one pass.

I actually think that "export *" already subsumes all the complication
of nested modules, because it creates a similar (but more general)
kind of 'exports' dependency. In addition, validation now has to
happen in dependency order and/or deal with export cycles (and detect
non-wellfounded cycles).

The notorious "import *", however, is far worse. With that, you don't
generally know what's in scope before you know what any module name
refers to -- and vice versa! In general, resolving this requires an
algorithm with backtracking, which obviously is a no-go.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Invoke trap (was: May 21, 22, 23 TC39 Meeting Notes)

David Bruant-5
In reply to this post by Rick Waldron
Le 02/06/2013 09:46, Rick Waldron a écrit :

> 4.4 Proxies
>
> Proxy Invoke Trap and wrong |this|-binding on built-in methods
>
> AWB: with current default behavior of “get”, “Caretaker” will break on
> built-ins such as Date, because the |this| binding is by default set
> to the proxy, so the Date built-in method will not find the correct
> private state.
> ARB: Same issue with binary methods
> ...
> STH: We should add invoke trap but not change the object model
> MM: Pleasant to have. Separate from private state.
> AWB: used to think this was an issue with proxies, but convinced that
> it’s an API issue: we need to provide default handlers that do the
> right thing, and which users can subclass. In particular, want a
> handler that, on forwarding, rebinds |this| to the target.
> STH: If you want to proxy a Date method the underlying `this` needs to
> be a non wrapped Date object.
Doesn't this break encapsulation?

var d = new Date();
var pd = new Proxy(d, {
invoke: function(target, name, thisArg, args){
return target[name].apply(thisArg, args)
}
})

var pt = pd.getTime(); // calls the invoke trap

// in a mixed-trusted context with access to pd:
var ppd = new Proxy(pd, {
invoke: function(target, name, thisArg, args){
// does the actual unwrapped date object leak through thisArg?
}
});

var ppt = ppd.getTime();

In any case, what is the following supposed to do:

Date.prototype.getTime.call( new Proxy(new Date(), handler) )

I imagine we would want this to work too. Is this going through the
invoke trap as well? The question stands for all new "class-specific"
(Map, Set, etc.) methods that would be dot-called with a proxy as first
argument.

If the problem being solved is making Date (and Map, Set, etc) built-in
methods works on wrapped objects, I feel the invoke trap is only a
partial solution.


I intuit (but have no proof) that for Date.prototype.getTime.call to
work on proxies, there is a need for class-specific traps.
* Object properties have specific traps to intermediate access
(has/get/set/defineProperty/keys, etc.),
* [[Prototype]] has specific traps to intermediate access
(get/setPrototypeOf)
* [[Extensible]] has a specific trap to intermediate access
(preventExtensions)
* [[Call]] has a specific trap to intermediate access (apply)
* [[Construct]] has a specific trap to intermediate access (construct)
* Some other things that are somewhat internal (@@iterator, @@class,
etc.) are exposed as symbols and are mediated via object
properties-related trap

The pattern I see is that a good share of object internal properties
(ES5.1 - 8.6.2 - Table 8 and Table 9) have traps dedicated to mediate
access.

The case of functions is interesting. There are traps that are only
relevant when the target is a function. In that regard, adding traps
that are specific to accessing the Date internal [[Time]] value or
specific traps to mediate access to [[MapData]] isn't any different than
the current specific traps that mediate [[Call]] or [[Construct]]

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Invoke trap

Brandon Benvie-2
On 6/7/2013 12:53 PM, David Bruant wrote:
Le 02/06/2013 09:46, Rick Waldron a écrit :
4.4 Proxies

Proxy Invoke Trap and wrong |this|-binding on built-in methods

AWB: with current default behavior of “get”, “Caretaker” will break on built-ins such as Date, because the |this| binding is by default set to the proxy, so the Date built-in method will not find the correct private state.
ARB: Same issue with binary methods
...
STH: We should add invoke trap but not change the object model
MM: Pleasant to have. Separate from private state.
AWB: used to think this was an issue with proxies, but convinced that it’s an API issue: we need to provide default handlers that do the right thing, and which users can subclass. In particular, want a handler that, on forwarding, rebinds |this| to the target.
STH: If you want to proxy a Date method the underlying `this` needs to be a non wrapped Date object.
Doesn't this break encapsulation?

var d = new Date();
var pd = new Proxy(d, {
invoke: function(target, name, thisArg, args){
return target[name].apply(thisArg, args)
}
})

var pt = pd.getTime(); // calls the invoke trap

// in a mixed-trusted context with access to pd:
var ppd = new Proxy(pd, {
invoke: function(target, name, thisArg, args){
// does the actual unwrapped date object leak through thisArg?
}
});

var ppt = ppd.getTime();

In any case, what is the following supposed to do:

Date.prototype.getTime.call( new Proxy(new Date(), handler) )

I imagine we would want this to work too. Is this going through the invoke trap as well? The question stands for all new "class-specific" (Map, Set, etc.) methods that would be dot-called with a proxy as first argument.

If the problem being solved is making Date (and Map, Set, etc) built-in methods works on wrapped objects, I feel the invoke trap is only a partial solution.


I intuit (but have no proof) that for Date.prototype.getTime.call to work on proxies, there is a need for class-specific traps.
* Object properties have specific traps to intermediate access (has/get/set/defineProperty/keys, etc.),
* [[Prototype]] has specific traps to intermediate access (get/setPrototypeOf)
* [[Extensible]] has a specific trap to intermediate access (preventExtensions)
* [[Call]] has a specific trap to intermediate access (apply)
* [[Construct]] has a specific trap to intermediate access (construct)
* Some other things that are somewhat internal (@@iterator, @@class, etc.) are exposed as symbols and are mediated via object properties-related trap

The pattern I see is that a good share of object internal properties (ES5.1 - 8.6.2 - Table 8 and Table 9) have traps dedicated to mediate access.

The case of functions is interesting. There are traps that are only relevant when the target is a function. In that regard, adding traps that are specific to accessing the Date internal [[Time]] value or specific traps to mediate access to [[MapData]] isn't any different than the current specific traps that mediate [[Call]] or [[Construct]]

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

I believe the purpose of adding multiple types of handlers [1] was to address this and similar issues.

In the case of the get, set and invoke traps, there is a choice to be made when forwarding the property get/set or the invoked method: should the value of this in a target’s accessor or method be set to the proxy object or to the target object? Either choice can be sensible, depending on your application.

The DelegatingHandler implements get, set and invoke in such a way that this inside forwarded accessors or method invocations remains bound to the receiver argument. Proxies using the DelegatingHandler can thus be used as prototypes for other objects: they leave the this-binding intact upon forwarding.

...

ForwardingHandler is itself a subclass of DelegatingHandler (so it comes with an appropriate default implementation for all Proxy traps). It overrides the get, set and invoke traps so that forwarded accessors or method calls get run with this set to the target object.


[1] http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12