Re: Are Private name and Weak Map the same feature? and the Assoc API

On 21 December 2011 13:33, David Bruant wrote: > Le 21/12/2011 11:25, Andreas Rossberg a écrit : >> In essence, you are introducing two separate types of private names, >> but the distinction only is observable in situations that the >> implementer should not need to thi

Re: Are Private name and Weak Map the same feature? and the Assoc API

On 21 December 2011 12:41, Sam Tobin-Hochstadt wrote: > On Wed, Dec 21, 2011 at 5:25 AM, Andreas Rossberg wrote: >> >>>> Hm, isn't this example rather demonstrating that the ability to do >>>> self stealing -- i.e., the lack of lexical `this' -- is viol

Re: Are Private name and Weak Map the same feature? and the Assoc API

On 19 December 2011 16:56, Tom Van Cutsem wrote: > > I think I don't have a problem with widening the type of the name parameter > of all of these traps from String to Object. Then a proxy handler can at > least test whether it is intercepting a private name or a normal property. Widening the "ty

Re: Are Private name and Weak Map the same feature? and the Assoc API

On 20 December 2011 21:06, David Bruant wrote: > Le 20/12/2011 14:45, Andreas Rossberg a écrit : >> On 17 December 2011 00:24, Sam Tobin-Hochstadt wrote: >>> You might want to implement an object with a private field and a >>> public method like this: >>> &g

Re: Are Private name and Weak Map the same feature? and the Assoc API

On 17 December 2011 00:24, Sam Tobin-Hochstadt wrote: > > I used to think this way about private names and proxies, and argued > for this position. However, I was wrong and it's a bad idea.  Here's > why: > > You might want to implement an object with a private field and a > public method like thi

Re: Have the scope accessible as an object and implement a new with operator / block

On 20 December 2011 11:51, Xavier MONTILLET wrote: > Well what about you add an if that checks whether scope is used or not > and if it is disables these optimizations? That's what's done for things like the `arguments' object. And it's an ugly mess, in terms of semantics as well as implementatio

Re: Have the scope accessible as an object and implement a new with operator / block

On 20 December 2011 11:24, Xavier MONTILLET wrote: > What kind of optimizations? Optimizations such as putting variables in registers, putting variables on the stack, overlaying variables with disjoint life times, eliminating some variables entirely, minimizing closure environments, to name just

Re: migrating `let' and `const'

On 16 November 2011 20:03, Brendan Eich wrote: > On Nov 16, 2011, at 4:18 AM, Erik Corry wrote: > >> In

Re: Alternative syntax for <|

On 16 November 2011 20:45, Erik Arvidsson wrote: > Sorry for being too brief. Today the following works. > > f(); > ... > function f() { ... } > > but the following does not: > > f(); > ... > let f = function f() {}; > > I think it is important that we keep the forward reference behavior > with cl

Re: Alternative syntax for <|

On 16 November 2011 20:12, Erik Arvidsson wrote: > One thing that all of these discussions are missing is the hoisting > property of function and any possible future classes. If we use "let > Point = ..." we lose all hoisting and the order of your declarations > starts to matter and we will end up

Re: (Almost) everything is expression

On 11 November 2011 12:48, François REMY wrote: > I think you strongly underestimate the "distinction" problem. It's *not* > possible to make any difference between the "foo" statement and the "print" > statement of your sample, from the compiler point of view. Why would the > "foo" statement be t

Function proxies without explicit construct trap

I think the specification of [[Construct]] for function proxies may not currently be doing what it is intended to do. If the proxy does not have a construct trap, the method simply delegates to the [[Construct]] method of the call trap. AFAICS, that has two consequences: 1. The prototype is taken

Re: What do we still need from a class-like abstraction (was: `this`: methods versus functions)

language change that would enable > a revision of traitsjs to run efficiently on ES-nest-next JSVMs. > I say ES-next-next because it is too late to consider any such language > change for ES-next. However, implementation experiments need not wait. > > On Thu, Nov 10, 2011 at 7:19 AM, Andreas R

Re: `this`: methods versus functions

On 10 November 2011 15:58, Axel Rauschmayer wrote: > I wonder if it made a difference if `this`was always stored in an > > environment (instead of an execution context). Then block lambdas could find > > them via the scope chain. > > If I understand you correctly, then yes, this is definitely poss

Re: `this`: methods versus functions

On 10 November 2011 15:23, Axel Rauschmayer wrote: > I wonder if it made a difference if `this`was always stored in an > environment (instead of an execution context). Then block lambdas could find > them via the scope chain. If I understand you correctly, then yes, this is definitely possible in

Re: `this`: methods versus functions

On 10 November 2011 14:49, Axel Rauschmayer wrote: > getX() is designed for a dynamic `this` (i.e. `this` is an instance of > InnerPoint). My proposal would allow an external party to switch to lexical > `this` (=== function Outer), simply by invoking it as a (non-method) > function. I can see how

Re: `this`: methods versus functions

On 10 November 2011 01:15, Mark S. Miller wrote: > On Wed, Nov 9, 2011 at 4:00 PM, Brendan Eich wrote: >> We talked about lexical this for functions long ago (Jan. 2008? at Google >> anyway) and IIRC Mark found a subtler flaw. > > I think my original example was smaller and more elegant. But the

Re: making |this| an error (was Re: for own(...) loop)

On 9 November 2011 16:10, John J Barton wrote: > I'm sure this has been discussed before, but isn't is possible and > desirable to make |this| illegal in "using strict;" when it can be > determined from the AST alone that |this| will bind to |window|?  eg: > >   Object.keys(foo).forEach(function(k

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On 9 November 2011 00:16, Mark S. Miller wrote: > On Tue, Nov 8, 2011 at 12:50 PM, Andreas Rossberg > wrote: >> >> On 8 November 2011 20:46, Mark S. Miller wrote: >> > Nevertheless, I see your point. Many defensive ES5 abstractions will be >> > less >>

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On 8 November 2011 20:46, Mark S. Miller wrote: > In general, for an object to be defensive, much of the surface reachable > from it by transitive prototype and reflective property traversal should > usually be frozen, and at least non-extensible. This is possible to express > in ES5 >

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On 8 November 2011 20:29, Andreas Rossberg wrote: > On 8 November 2011 18:47, David Bruant wrote: >> "Given that direct proxies are not in a position to violate any of the >> *non-configurability or non-extensibility constraints* of their wrapped >> target, it sh

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On 8 November 2011 18:47, David Bruant wrote: > "Given that direct proxies are not in a position to violate any of the > *non-configurability or non-extensibility constraints* of their wrapped > target, it should be safe to replace an existing normal object by a > direct proxy wrapping that object

Re: [Proxies] Refactoring prototype climbing in the spec

On 7 November 2011 16:54, Tom Van Cutsem wrote: > I wrote up an initial (but fairly complete) draft of a proposed refactoring > of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the way > in which these algorithms climb the prototype > chain: 

Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On 3 November 2011 23:55, Mark S. Miller wrote: >> If I understood Mark correctly, the features needed for SES are >> already part of ES.5 and are shipping in browsers >> >> (and hence don't bear upon future features).  Did I misunderstand? > > These do bear on future features in three ways: > > 1

Re: An array destructing specification choice

On 7 November 2011 22:46, Brendan Eich wrote: > On Nov 7, 2011, at 3:04 AM, Andreas Rossberg wrote: >> One possible semantics could be treating >> >>  let [x, y, z, ...r] = e >> >> as equivalent to >> >>  let {0: x, 1: y, 2: z, ..._r} = e >>  le

Re: An array destructing specification choice

On 7 November 2011 18:42, Allen Wirfs-Brock wrote: > > or >    let [first,second] = "abc"; Yes, that's a more convincing example -- although we should probably be aware that users will then also do let [x, y, ...s] = somestring and expect it to slice a string efficiently. /Andreas __

Re: An array destructing specification choice

On 7 November 2011 17:34, Allen Wirfs-Brock wrote: >>  It is just another way to >> silently inject an `undefined' that is tedious to track down.  We >> already have too many of those... > > It is how the language currently behaves in all situations where an object is > needed but a primitive val

Re: An array destructing specification choice

On 7 November 2011 17:07, Allen Wirfs-Brock wrote: >>  let {x} = 666 >> >> which will be refuted, by raising a TypeError. > > No, > > It does ToObject(666) and then looks for the "x" property of the resulting > wrapper object. Ouch, really? I don't see that in the proposal (http://wiki.ecmascri

Re: An array destructing specification choice

On 5 November 2011 19:55, Brendan Eich wrote: > On Nov 5, 2011, at 9:38 AM, Allen Wirfs-Brock wrote: > >> In a similar vain, what is the value of r in: >> >> let [z,y,...r] = {0:0, 1:1, 2:2, length: 3, 3:3,4:4}; >> >> should it be [2] or [2,3,4]  (and if the latter how is that determined)? > > The

Re: An array destructing specification choice

On 5 November 2011 17:44, Brendan Eich wrote: > Destructuring is "irrefutable" in that it desugars to assignments from > properties of the RHS. It is not typed; it is not refutable I don't think that's true, at least not in the usual sense of "irrefutable pattern". Because you can write let {

Re: Globalization API working draft

On 3 November 2011 01:12, David Herman wrote: > ES6 modules are not extensible, for a number of reasons including > compile-time variable checking. But of course API evolution is critical, and > it works; it just works differently. Monkey-patching says "let the polyfill > add the module exports

Re: testable specification

On 27 October 2011 13:35, David Bruant wrote: > +1. Where the spec is already almost pseudo-code, its readability would > improve if it was, in fact, pseudo-code. But would an extra interpreter be > needed or couldn’t one just implement the ES-262 constructs (execution > contexts etc.) in an exist

Re: missing non-rest_parameters should throw error

On 26 October 2011 20:27, Allen Wirfs-Brock wrote: > > 1) arguments is needed for backwards compatability (no migration tax) > 2) it is useful with destructing parameters: > function ({a,b,c}, [x,y]) { >   if (arguments.length < 2) ... >   ... >    var arg1obj = argruments[0]; >    ... All langua

Re: Protocol for "new" and "instanceof"?

On 22 October 2011 01:08, Axel Rauschmayer wrote: > Reified names (private or otherwise) are a very powerful mechanism. I’m not > aware of another programming language that does this (possibly Common Lisp > with its symbols, but I don’t know enough about them). It’s good to have > them, because th

Re: Why isn't FunctionExpression a PrimaryExpression?

One concern might be that we probably cannot make arrow notation (if we introduce it) a primary expression, and it might be confusing if they have different precedence. I also think it is easier to parse for the human reader when he sees (function f() { ... })() instead of function f() { ..

Re: Direct proxies strawman

On 19 October 2011 05:08, David Herman wrote: >>> It’s still as easy to create such “virtual” proxies: just pass a fresh >>> empty object (or perhaps even null?) >> >> Please, make it null. So much more pleasant (and avoids needless >> allocation). >> (The only downside of allowing null to mean "n

Re: Direct proxies strawman

On 18 October 2011 17:48, Tom Van Cutsem wrote: > 2011/10/18 Andreas Rossberg >> >> First, Proxy.startTrapping (a.k.a. Proxy.attach). As far as I can see, >> this implies a significantly more general 'become' operation than the >> current semantics. I don&#x

Re: [Harmony proxies] proxy, receiver, target: an alternative to additional arguments

On 18 October 2011 13:45, David Bruant wrote: > Another alternative would be to do natively what we've been doing in code > which is that when a call is trapped, instead of using the handler, an new > object is created. This object inherits from the handler and has at the own > layer the 3 propert

Re: Direct proxies strawman

On 18 October 2011 17:08, David Bruant wrote: > Ok for typeof. But there are other places where [[Call]] is used and the > proxy is expected to (indirectly) expose it. For instance bind: > - > var fpb = Function.prototype.bind; > var bind = fpb.bind(fpb); > var p = Proxy.for(function(){}, {});

Re: Direct proxies strawman

On 17 October 2011 21:15, Tom Van Cutsem wrote: > I just finished a first draft of the > strawman: . > Feedback welcome. Hi Tom, this looks nice, but a couple of things confuse me. First, Proxy.startTrapping (a.k.a. Proxy.attach).

Re: Minor issues with proxies

On more thing: * Filter[Own]Enumerable: don't anticipate the case that desc might be undefined in step 7.c.4. (The respective JS default traps are broken in a similar manner.) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozi

Re: Feedback request: a ES spec. organization experiment

On 12 October 2011 18:34, Allen Wirfs-Brock wrote: > > http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:11.1.5-alternatives-2.pdf > has a 5th alternative version that follows your suggested structure.  Note > that I classified semantic functi

Re: Feedback request: a ES spec. organization experiment

On 12 October 2011 02:32, Allen Wirfs-Brock wrote: > The experiments are shown > in http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:11.1.5-alternatives.pdf > This contains four versions of section 11.5.1  (Object literals).  Each > section i

Re: Minor issues with proxies

On 12 October 2011 11:00, Andreas Rossberg wrote: > On 11 October 2011 20:49, Tom Van Cutsem wrote: >> Proxy.create{Function} is now present on >> <http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics>. Let us >> know if you spot any further holes. > &g

Re: Minor issues with proxies

On 11 October 2011 20:49, Tom Van Cutsem wrote: > Proxy.create{Function} is now present on > . Let us > know if you spot any further holes. Great, thanks! One comment only: > 1. Let handler be ToObject(O) I wonder, is that usefu

Re: Proxy-induced impurity of internal methods

On 10 October 2011 15:38, Tom Van Cutsem wrote: > This point was previously noted, see: > > It was brought up at the March 2011 meeting, and IIRC we were in agreement > that the spec. should be adapted to remove the redundant > getPr

Re: holes in spread elements/arguments

On 7 October 2011 17:47, David Herman wrote: > I don't think we can get away with repurposing _ as a pattern sigil, since > it's already a valid identifier and used by popular libraries: > > http://documentcloud.github.com/underscore/ > > In my strawman for pattern matching, I used * as the "

Re: Proxy-induced impurity of internal methods

On 5 October 2011 21:00, Andreas Rossberg wrote: > On 5 October 2011 18:57, Andreas Rossberg wrote: >> FIXING PROXIES >> >> A particularly worrisome side effect is fixing a proxy. The proxy >> semantics contains a lot of places saying "If O is a trapping proxy,

Re: holes in spread elements/arguments

On 5 October 2011 21:19, Sean Eagan wrote: > However, I don't see why variable declaration array destructuring > binding and parameter lists should be different in any way. The only > current syntactic difference between them is elision: > > // allowed > function f([,,x]){} > // disallowed >

Re: Proxy-induced impurity of internal methods

On 6 October 2011 06:34, Allen Wirfs-Brock wrote: > On Oct 5, 2011, at 9:57 AM, Andreas Rossberg wrote: >> In summary, I'm slightly worried. The above all seems fixable, but is >> that all? Ideally, I'd like to see a more thorough analysis of how the >> addition o

Re: Proxy-induced impurity of internal methods

On 5 October 2011 18:57, Andreas Rossberg wrote: > FIXING PROXIES > > A particularly worrisome side effect is fixing a proxy. The proxy > semantics contains a lot of places saying "If O is a trapping proxy, > do steps I-J." However, there generally is no guarantee th

Proxy-induced impurity of internal methods

Proxies invalidate one fundamental assumption of the current ES spec, namely that (most) internal methods are effectively pure. That has a couple of consequences which the current proxy proposal and semantics seem to ignore, but which we need to address. OBSERVABILITY & EFFICIENCY In ES5, intern

Minor issues with proxies

Hi Mark, Tom! I understand that you are currently working on finalizing a number of aspects of the proxies proposal, so I thought I'd send my current notes on issues I discovered. (Sorry if I'm a bit late with that, but I just returned from travelling.) Here is a list of minor issues. I'll send a

Re: Implementation considerations in the ECMAScript standard (was {Weak|}{Map|Set})

But I'll leave it at that, nobody wants another longish bike-shedding discussion. On 16 September 2011 18:50, David Bruant wrote: > Changing the subject to something more relavant. > > Le 16/09/2011 15:36, Andreas Rossberg a écrit : >> >> On 16 September

Re: {Weak|}{Map|Set}

On 16 September 2011 19:42, Mark S. Miller wrote: > Does anyone see anything wrong with "EphemeralMap"? Yes. It's a longish name, and one that I will never be able to remember how to spell correctly. And to most programmers it probably sounds about as reassuring as "endofunctor" or "catamorphism"

Fwd: {Weak|}{Map|Set}

[Forgot the list.] -- Forwarded message -- From: Andreas Rossberg Date: 16 September 2011 15:35 Subject: Re: {Weak|}{Map|Set} To: David Bruant On 16 September 2011 15:17, David Bruant wrote: >> Well yes, but that's part of programming. In practice, all resou

Re: {Weak|}{Map|Set}

On 16 September 2011 13:52, David Bruant wrote: > > Furthermore, let imagine for a minute that i need an ECMAScript > implementation for programs i write which i know (for some reason) all are > short live and use a maximum finite amount of memory i know. Based on this > knowledge (i admit this to

Re: IDE support?

On 16 September 2011 02:12, Mike Shaver wrote: > On Thu, Sep 15, 2011 at 9:02 AM, Andreas Rossberg wrote: >> On 14 September 2011 00:00, Brendan Eich wrote: >>> >>> So, static+dynamic. The static side has some powerful algorithms to bring >>> to bear. Dyna

Re: {Weak|}{Map|Set}

On 15 September 2011 17:47, Allen Wirfs-Brock wrote: > No the normal use case for WeakMaps is simply to make associations between > objects and arbitrary values.  The special GC behavior is necessary to avoid > memory leaks, but that is a quality of implementation issue, not a use case. Just li

Re: IDE support?

On 14 September 2011 00:00, Brendan Eich wrote: > > So, static+dynamic. The static side has some powerful algorithms to bring to > bear. Dynamic is necessary due to eval and kin, and gives strictly more > information (and more relevant information!). Nitpick: I believe you are mistaken about th

Re: IDE support?

On 13 September 2011 21:32, Wes Garland wrote: > > When I write shell programs, and JS programs, I keep an extra terminal > window open to a spare shell or a JS REPL.  I try stuff. Stuff that works, I > copy into my program.  Then I run my program - which happens quickly, > because the compiler is

Re: IDE support?

On 13 September 2011 16:48, Brendan Eich wrote: > On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote: >> >> * There are extra costs in space and time to doing the runtime analysis. >> * Compile time is runtime, so there are severe limits to how smart you >> can

Re: {Weak|}{Map|Set}

On 15 September 2011 09:10, Brendan Eich wrote: > On Sep 14, 2011, at 11:09 PM, Allen Wirfs-Brock wrote: > >> I would prefer ObjectMap (the keys are restricted to objects). > > Now that you point it out (again), I agree. I don't. :) It is true to some extent that WeakMap is GC jargon -- but as Ma

Re: IDE support?

On 13 September 2011 09:33, Brendan Eich wrote: > > You are simply way out of date on JS optimizing VMs, which (based on work > done with Self and Smalltalk) all now use "hidden classes" aka shapes and > polymorphic inline caching to optimize to exactly the pseudo-assembly you > show, prefixed

Re: __doc__ for functions, classes, objects etc.

On 5 September 2011 16:12, Dmitry Soshnikov wrote: > ** > On 05.09.2011 13:26, Andreas Rossberg wrote: > > I am indifferent about the general idea of a doc interface, > > > Then I don't think incorrect judging about the concept of an "abstraction" > is a

Re: __doc__ for functions, classes, objects etc.

On 4 September 2011 21:45, Brendan Eich wrote: > On Sep 6, 2011, at 1:52 PM, Dmitry Soshnikov wrote: > > > (1) to standardize `toString` (for this particular case -- do not remove > comments inside); > > > > If the (1) is not possible (why by the way?), > > Because comments are not saved in the c

Re: Function proxy length (Was: length property value for functions with parameter enhancements)

On 31 August 2011 15:21, Tom Van Cutsem wrote: > I coded up a hypothetical Proxy.createConstructor function that creates a > function proxy initialized according to ES5.1 section 13.2: < > https://gist.github.com/1183514> Nit: invoking callTrap.call assumes that callTrap has an actual call meth

Re: Function proxy length (Was: length property value for functions with parameter enhancements)

On 30 August 2011 18:41, David Bruant wrote: > This would facilitate the author work when it comes to creating functions > that look like functions without having to always include some > initialization code for .length, .prototype and such. > It will still be possible to opt-out of .length or .p

Re: length property value for functions with parameter enhancements

On 29 August 2011 01:36, Allen Wirfs-Brock wrote: > On Aug 27, 2011, at 6:12 AM, Andreas Rossberg wrote: >> True, and actually, there are more issues with length & function >> proxies. I don't have my notes with me right now, but for example, it >> i

Re: length property value for functions with parameter enhancements

On 27 August 2011 00:34, Allen Wirfs-Brock wrote: > Something we need to define for ES.next is how to compute the length > property value for functions whose formal parameter list includes "optional" > and/or rest parameters. True, and actually, there are more issues with length & function proxie

Re: Block scoping and redeclarations

On 25 August 2011 18:57, Brendan Eich wrote: > On Aug 25, 2011, at 6:17 AM, Andreas Rossberg wrote: > >>> There is no "before and after" or "both" here. Hoisting first, with rule 1 >>> enforced; then rule 2 checking. Relative source order of declaratio

Re: Block scoping and redeclarations

On 24 August 2011 18:03, Brendan Eich wrote: > On Aug 24, 2011, at 2:03 AM, Andreas Rossberg wrote: >> On 23 August 2011 21:18, Brendan Eich wrote: >>> I think the rules we have discussed are: >>> >>> 1. Any hoisting of var across let binding the same name (w

Re: Object.methods

On 24 August 2011 01:07, Allen Wirfs-Brock wrote: > Also there can be real problems with exposing too much program metadata > directly to the application layer. I've had lots of experience with Smalltalk > environments where this was the case and it leads to a muddling of the > metalayers and t

Language modes (Was: Block scoping and redeclarations)

> That's not to say that I couldn't live with more fine-grained rules, I > just don't consider them worthwhile. Ultimately, we want to morally > deprecate "var" for Harmony mode, so introducing too many extra rules > around it seems a bit unjustified, unless there is a very good reason. Btw, we ha

Re: Block scoping and redeclarations

On 23 August 2011 21:18, Brendan Eich wrote: > I think the rules we have discussed are: > > 1. Any hoisting of var across let binding the same name (whether explicit, or > as in catch blocks and comprehensions, implicit) is an early error. > > 2. Redeclaration of a name in the same block scope vi

Re: Block scoping and redeclarations

On 23 August 2011 19:14, Allen Wirfs-Brock wrote: > > On Aug 23, 2011, at 5:31 AM, Andreas Rossberg wrote: > >> We are currently in the process of implementing block scoping for V8 >> (http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings). > > The

Block scoping and redeclarations

We are currently in the process of implementing block scoping for V8 (http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings). Brendan and Dave suggest that certain combinations of `let' and `var' should be an error (more precisely, a syntax error, I assume). However, there are variou

Re: Where in spec does it explain why setting the value of an existing property will change its [[Enumerable]] attribute.

On 17 August 2011 21:24, John-David Dalton wrote: > Another odd thing is that V8 uses the `Array#push` internally for > `Object.defineProperties`. > I noticed that if I set `Array.prototype.push = 1;` using > `Object.defineProperties(…)` would error complaining about `push` not > being a function.

Re: July TC39 meeting notes, day 1

On 12 August 2011 13:53, Tom Van Cutsem wrote: > I think I found a compelling and easy-to-understand > rule for determining whether or not a trap needs access to proxy/receiver: > if the trap deals with inherited properties, it needs access to |proxy|. > > Using that rule, the following traps requ

Re: July TC39 meeting notes, day 1

On 9 August 2011 19:25, Kevin Reid wrote: > On Tue, Aug 9, 2011 at 01:17, Andreas Rossberg wrote: >> On 8 August 2011 18:46, Kevin Reid wrote: >>> On Mon, Aug 8, 2011 at 08:50, Andreas Rossberg wrote: >>>> Arguably, making a proxy trap return getters/setters seems

Re: July TC39 meeting notes, day 1

On 8 August 2011 18:46, Kevin Reid wrote: > On Mon, Aug 8, 2011 at 08:50, Andreas Rossberg wrote: >> I would welcome removing the extra receiver (or proxy) arguments from >> get and set traps. However, it seems to me that the main reason, >> currently, for having them is th

Re: July TC39 meeting notes, day 1

On 4 August 2011 19:34, Brendan Eich wrote: > On Jul 31, 2011, at 1:04 PM, Sean Eagan wrote: > >> A 'receiver' argument is not needed because it would never be >> different than the proxy, and the proxy can either be passed as an >> argument or stored either as an own property of the handler, or a

Re: An experiment using an object literal based class definition pattern

On 4 August 2011 22:57, Allen Wirfs-Brock wrote: > Using these two new ideas and other active object literal enhancement > proposals it is pretty easy to compose a class-like declaration.  For > example the SkinnedMesh from > the http://wiki.ecmascript.org/doku.php?id=harmony:classes proposal can

Re: July TC39 meeting notes, day 1

On 30 July 2011 04:57, Brendan Eich wrote: > Proxies have two prototype implementations now: Firefox since 4, and now V8 > (http://code.google.com/p/v8/source/detail?r=8733) -- not sure when that > shows up under a flag in Chrome canaries, someone from Google will know. If you invoke a current V8

Re: Adding methods to {Array,String}.prototype

On 29 July 2011 19:08, Brendan Eich wrote: > > I did not mean multimethods ("generic functions" is a confusing term, since > it also means functions that work for parameters of any time; also "generic" > suggests "generics", i.e. type parameters). "Generic" is a heavily overloaded term. I forgo

Re: July TC39 meeting notes, day 1

On 28 July 2011 20:34, David Bruant wrote: > Le 28/07/2011 19:52, Andreas Rossberg a écrit : >> On 28 July 2011 10:35, David Bruant wrote: >>> Le 28/07/2011 06:21, Brendan Eich a écrit : >>>> == Handler access to proxies == >>>> >>>> Proxy

Re: July TC39 meeting notes, day 1

On 28 July 2011 10:35, David Bruant wrote: > Le 28/07/2011 06:21, Brendan Eich a écrit : >> >> == Handler access to proxies == >> >> Proxy handler traps need to receive the proxy as a parameter: first, or >> last? >> >> Last allows trap implementors to leave |proxy| off. It's also a compatible >>

Re: Type of property names, as seen by proxy traps

"tampered", not "hampered", of course... On 14 July 2011 12:52, Andreas Rossberg wrote: > Very much appreciated. Given all the nasty mutability in JS, I think > for the non-normative JS implementations you also might want to note > that it assumes that nobody has

Re: Type of property names, as seen by proxy traps

doesn't need >> to coerce again. Finally, `keys' does not need to coerce its own result >> array, since it is simply a filtered version of an already fresh, coerced >> array. >> Perhaps all self-sends to fundamental traps should be expressed

Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)

I fully agree that isProxy sounds like a bad idea. It just breaks the proxy abstraction. /Andreas On 13 July 2011 10:26, Andreas Gal wrote: > > I really don't think IsProxy is a good idea. It can lead to subtle bugs > depending on whether an object is a DOM node, or a wrapper around a DOM node >

Re: using Private name objects for declarative property definition.

On 9 July 2011 17:48, Brendan Eich wrote: > > Adding names as a distinct reference and typeof type, extending > WeakMap to have as its key type (object | name), adds complexity > compared to subsuming name under object. It seems to me that you are merely shifting the additional complexity from on

Re: using Private name objects for declarative property definition.

On 9 July 2011 14:42, Sam Tobin-Hochstadt wrote: > Unlike Names, strings and numbers are forgeable, so if they were > allowed as keys in WeakMaps, the associated value could never be > safely collected.  Names, by contrast, have identity. Of course you are right, and I shouldn't post in the middl

Re: Array generation

On 10 July 2011 22:23, David Herman wrote: > Another common and useful fusion of two traversals that's in many Schemes is > map-filter or filter-map: > >    a.filterMap(f) ~~~ [res for [i,x] of items(a) let (res = f(x, i)) if (res > !== void 0)] > > I rather arbitrarily chose to accept both null

Re: using Private name objects for declarative property definition.

On 9 July 2011 00:24, Brendan Eich wrote: > On Jul 8, 2011, at 2:43 PM, Andreas Rossberg wrote: >> One minor suggestion I'd have is to treat names as a proper new >> primitive type, i.e. typeof key == "name", not "object". That way, it >> can be defin

Re: using Private name objects for declarative property definition.

On 8 July 2011 21:16, Allen Wirfs-Brock wrote: > The current versions of the private names proposal > http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects  simply > exposes a constructor for creating unique values can be be used as property > keys: Of the several private names prop

Re: Minor type confusion in proxies proposal?

user attributes on descriptor objects. That is, we should either support such attributes properly, i.e. have them consistently flow both ways (from clients to traps and vice versa). Or we do not support them at all, i.e. filter them out everywhere. /Andreas On 8 July 2011 10:59, Andreas Rossberg wrote:

Re: Minor type confusion in proxies proposal?

defineProperties to go through defineProperty, instead of calling the internal [[DefineOwnProperty]] directly. /Andreas On 6 July 2011 14:55, Andreas Rossberg wrote: > On 3 July 2011 13:29, Tom Van Cutsem wrote: >> Comments? > > Looks good to me. I agree with Mark's comment

Re: Type of property names, as seen by proxy traps

On 7 July 2011 19:35, David Bruant wrote: >> No, with the current keys default trap (calling >> this.getOwnPropertyNames()) there is no double conversion. Only one at >> the exit of the keys trap. There would be 2 conversions if the "keys" >> trap had the proxy argument (based on >> http://wiki.ec

Re: Type of property names, as seen by proxy traps

On 7 July 2011 17:58, Brendan Eich wrote: > On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote: > >> On 7 July 2011 16:12, David Bruant wrote: >>>>> Derived traps as showed are written in JS for expository purposes. >>>>> Engines >>>>> wi

Re: Type of property names, as seen by proxy traps

On 7 July 2011 16:12, David Bruant wrote: >>> Derived traps as showed are written in JS for expository purposes. >>> Engines >>> will be free to optimize as they wish internally as long as the observed >>> behavior is the same. >> >> True, but optimizing that actually is more tricky than you might

<    3   4   5   6   7   8   9   >