On Oct 16, 2013, at 7:25 AM, Mark S. Miller wrote:
Keep in mind that if an object is non-extensible, its [[Prototype]] cannot be
changed.
And objects that are implemented using a Proxy don't use their [[Prototype]]
slot (a Proxy they doesn't have one) or necessarily even their target's
On Oct 15, 2013, at 6:40 AM, Mark S. Miller wrote:
On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg rossb...@google.com wrote:
On 15 October 2013 03:09, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I still don't get why so many JS programmer with a FP orientation want to
do
On Oct 15, 2013, at 7:22 AM, Russell Leggett wrote:
If we didn't have :: (which we don't now), I think people will continue to
simply use functions like what underscore does. Personally, I'm ok with that.
If I want to have unscoped extensions and live with the consequences - I will
be
On Oct 15, 2013, at 9:44 AM, Benjamin (Inglor) Gruenbaum wrote:
...
The big issue I see here is chaining.
`_.reduce(_.map(_.filter([1,2,3,4,5],x=x%2 === 0),x=2*x),(x,y)=x+y)`
Is a lot less readable than
`[1,2,3,4,5].filter(x=x%2===0).map(x=2*x).reduce((x,y)=x+y))`
On Oct 15, 2013, at 2:10 PM, Benjamin (Inglor) Gruenbaum wrote:
Not resolving this like o3 (or o6 really) sounds very strange. I think:
let attr = __proto__;
let o7 = new Object;
o7[attr] = p; // o7 inherits from p
Is the correct behavior here (why would it not invoke the setter?)
On Oct 15, 2013, at 3:19 PM, Dean Landolt wrote:
So just to be clear, the only way to add a __proto__ property to an existing
object is with Object.defineProperty?
Object.mixin(obj, {[__proto__]:42});
Allen
___
es-discuss mailing list
On Oct 14, 2013, at 9:49 AM, Mathias Bynens wrote:
On 2 Oct 2013, at 10:45, Petka Antonov petka_anto...@hotmail.com wrote:
In current version, this works just fine:
var let = 6;
Note that `let` was reserved in strict mode (only) in ES5, meaning that even
as per ES5 that snippet
On Oct 14, 2013, at 8:42 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
My take-away was that scoped extension methods are only bearable in a
language with a static, nominal class system (like C#), where the
additional lookup dimension can be resolved at compile time.
Right.
The
On Oct 14, 2013, at 11:06 AM, Brendan Eich wrote:
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
October 14, 2013 10:52 AM
I'm not sure I buy your Smalltalk has nominal class types assertion,
I defer to your Smalltalk expertise :-P. However, there's nothing I know of
that allows
On Oct 14, 2013, at 3:58 PM, Brendan Eich wrote:
Russell Leggett wrote:
It doesn't use dots, so it won't mask the difference between the normal
prototype chain with some additional scoped binding (for good or ill), but
along with it comes the clarity and comfort of lexical binding and also
On Oct 14, 2013, at 5:54 PM, Andrea Giammarchi wrote:
Allen my confusion is with o4 ... what happens once you re-set/assign its
`__proto__` there?
Is it just a normal property so new value will be set ?
Is it a magic inherited thing (it shouldn't) that will change the o4
prototype chain
On Oct 8, 2013, at 6:36 AM, Nathan Wall wrote:
Allen Wirfs-Brock wrote:
Nathan Wall wrote:
Set foo to bar.[[Baz]]
Does `foo` ever result in a non-undefined value if `bar` doesn't have
an own `[[Baz]]` property but inherits from an object that has an
internal `[[Baz]]` property
On Oct 8, 2013, at 10:38 AM, Brendan Eich wrote:
Claude Pache wrote:
It may be useful to recall that there are different concepts in the spec
that have a name enclosed in double square brackets. I have found these
three:
* attributes of object properties (Section 6.1.7.1) [1];
Note
On Oct 8, 2013, at 11:09 AM, Brendan Eich wrote:
I could go with internal slot. Is data necessary?
or perhaps just slot.
One concern with inventing terminology at this time is that we really don't
know how we will want to talk about language level private object state
assuming when it gets
this material will be gone from the next draft. At the last TC39 meeting we
agreed that they were unnecessary.
Allen
On Oct 7, 2013, at 8:23 AM, Claude Pache wrote:
According to the latest version of the ES6 draft, section 25.2 [1], the
std:iteration module exports these names:
*
On Oct 7, 2013, at 8:05 PM, Nathan Wall wrote:
This should be a quick answer; I'm just looking for clarity. Are there any
situations where internal data properties may be inherited? For example:
No never. Internal data properties are really properties at all. They are
really private
On Oct 7, 2013, at 9:56 PM, Nathan Wall wrote:
...
For instance, in the section for Object.prototype.toString (ES6 draft), steps
9-13 check to see if O has a [[X]] property, where X is some internal
data property. Based on my experience with Object.prototype.toString, I know
that has a
No, the closest yo a spec that we have is the spec
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.mixin
Andrea Giammarchi andrea.giammar...@gmail.com wrote:
___
es-discuss mailing list
es-discuss@mozilla.org
On Oct 1, 2013, at 3:10 AM, Andreas Rossberg wrote:
On 30 September 2013 18:20, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The lastest draft throws when doing an implicitly ToString conversion [1]
of a Symbol primitive value. This means that (aSymbol + suffix) or
(prefix + aSymbol) [2
On Oct 1, 2013, at 12:03 AM, André Bargull wrote:
Brandon Benvie mailto:bbenvie at mozilla.com
September 30, 2013 8:48 PM
I'm actually now really curious what the following does:
```
function foo(x, y = (() = { arguments[0] = foo; return bar })()) {
return [x, y];
}
Easy:
On Oct 1, 2013, at 1:22 PM, Claude Pache wrote:
Le 1 oct. 2013 à 19:33, Brendan Eich bren...@mozilla.com a écrit :
Allen Wirfs-Brock wrote:
Currently, that works for everything but null
and undefined, so I assume that this pattern is used quite a bit.
Do you think it really is?
I
On Sep 30, 2013, at 4:53 AM, Andreas Rossberg wrote:
On 30 September 2013 13:41, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
I can't remember any discussion about Object(Symbol()). Why should it be
disallowed?
/es-discuss
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 27, 2013 3:05 PM
This is Rev 19, The Sept. 27 Draft
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#september_27_2013_draft_rev_19
And the HTML is available at
http://people.mozilla.org/~jorendorff
Symbol.prototype.toString uses in in the current draft (see
http://esdiscuss.org/topic/a-new-es6-draft-is-available#content-4).
I suppose there is no reason not to make it directly accessible. What should
be the named of the property? It isn't necessarily a name which is why I used
On Sep 27, 2013, at 9:44 PM, Kevin Smith wrote:
All the noise we made about Object.extend was unclear? From jQuery:
https://github.com/jquery/jquery/blob/master/src/core.js#L157
Many similar functions, going back to Prototype's Object.extend:
Object.extend = function(destination,
On Sep 27, 2013, at 5:24 AM, Mark S. Miller wrote:
That's fine for an unregistered Symbol, i.e., one created by calling the
Symbol constructor. What about a registered Symbol, i.e., one created by
calling Symbol.for?
Perhaps, there could be a second optional parameter,
On Sep 27, 2013, at 7:52 AM, Erik Arvidsson wrote:
What's the use case for Symbol.keyFor?
The use case was actually suggested in a response to dherman earlier in this
thread when he mentioned sharing symbols between workers.
If you need to serialize an object with symbol keyed properties
This is Rev 19, The Sept. 27 Draft
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#september_27_2013_draft_rev_19
And the HTML is available at
http://people.mozilla.org/~jorendorff/es6-draft.html
Changes include:
Better internal cross-linking
Restored NoIn expression
Two thoughts below:
On Sep 26, 2013, at 11:31 AM, Brendan Eich wrote:
Anne van Kesteren mailto:ann...@annevk.nl
September 26, 2013 5:41 AM
What Tab meant is that within the platform only CR and CRLF are
normalized to LF and no other code points. This is true for HTML as
well.
This
character (and they probably are NOT showing up as line breaks
in their editor) into a template
On Sep 26, 2013, at 11:50 AM, Allen Wirfs-Brock wrote:
Two thoughts below:
On Sep 26, 2013, at 11:31 AM, Brendan Eich wrote:
Anne van Kesteren mailto:ann...@annevk.nl
September 26, 2013 5:41 AM
On Sep 26, 2013, at 1:59 PM, Brendan Eich wrote:
@ is the new dunder -- dunder at -- dat.
Among the no-symbol proposals, I like this best. (GUIDs, shudder.)
/be
I shudder to say this, having just finished my third complete redo of Symbols
in the ES6 draft, but I also like this proposal
On Sep 26, 2013, at 3:03 PM, Rick Waldron wrote:
On Thu, Sep 26, 2013 at 5:43 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
...
A negative is that it was decided that concise methods definitions create
enumerable properties and I don't think we really want these showing up
On Sep 26, 2013, at 3:13 PM, Rick Waldron wrote:
On Thu, Sep 26, 2013 at 6:02 PM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
No surprise here, but I also support using @ methods.
I don't. Please see my response to Kevin Smith:
On Sep 26, 2013, at 3:30 PM, Rick Waldron wrote:
On Thu, Sep 26, 2013 at 6:20 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
...
Maybe the exception could be enumerability exception could be concise methods
with string literal property names that do not parse as IdentifierName
On Sep 26, 2013, at 3:39 PM, Rick Waldron wrote:
The Symbol isn't exposed so therefore can't accidentally be used to
accidentally pave over the subclass instance object's events cache. As far as
the @RickWaldron@events Hungarian notation monstrosity is concerned: the
first thing I
On Sep 26, 2013, at 3:50 PM, David Herman wrote:
On Sep 26, 2013, at 3:48 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
I don't understand why this is happening. There was fairly strong consensus
on symbols at the last meeting, and nothing new has been brought to the
table.
On Sep 26, 2013, at 3:51 PM, Yehuda Katz wrote:
If that's the case, we haven't thought the registry through well enough. You
should get the cross-realm symbol through imports.
Imports don't cover the case where you want to have different instances (and
possible different versions) of the
On Sep 26, 2013, at 3:59 PM, Yehuda Katz wrote:
Sorry, that was too short.
I don't understand what using string literal specified, non-identifier
property names brings to the table to fundamentally alter the constraints
that we've been working with that led to the consensus at the last
On Sep 26, 2013, at 4:13 PM, Yehuda Katz wrote:
I don't understand why any registry is needed. Imagine a module
ember/symbols implemented like this, assuming some sharedSpace that modules
have access to cross-realms.
```
var guid = generated literal, symbol;
if (sharedSpace[guid]) {
On Sep 26, 2013, at 4:30 PM, David Herman wrote:
On Sep 26, 2013, at 4:26 PM, Rick Waldron waldron.r...@gmail.com wrote:
Thinking about this in terms of tooling, at even the terminal level, might
look like this: http://gyazo.com/f61d0e25366ce7e526c79ab7fa77cb17.png
No no, the GUID
On Sep 26, 2013, at 4:43 PM, David Herman wrote:
On Sep 26, 2013, at 4:22 PM, Mark S. Miller erig...@google.com wrote:
I am saying collision is an issue, but that it only seems that Symbols solve
it because we haven't yet designed the registry. So we should do so first,
and then
On Sep 26, 2013, at 4:51 PM, David Herman wrote:
On Sep 26, 2013, at 4:43 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Right, this is the first instance registers pattern. You still need to use
something like a GUID or naming convention to avoid accidental registration
collisions
On Sep 26, 2013, at 5:22 PM, David Herman wrote:
Am I not explaining this well? I feel like I've been trying to make this
point several times over in this thread.
probably in a earlier thread of this topic that I did't pay a lot of attention
too.
One of the biggest issues with GUID's
On Sep 26, 2013, at 8:44 PM, Mark S. Miller wrote:
I think an adequate registry is exactly the two static methods Allen proposed:
Symbol.for(aString) == aSymbol
Symbol.keyFor(aSymbol) == aString
where for all strings S
Symbol.keyFor(Symbol.for(S)) === S
I think we've discussed
On Sep 26, 2013, at 7:12 PM, Brendan Eich wrote:
Kevin Smith mailto:zenpars...@gmail.com
September 26, 2013 7:01 PM
- Symbols are surprisingly tricky at the spec level. (new Symbol() throws,
what?)
Allen should weigh in.
The spec. works for the latest version from last weeks
On Sep 25, 2013, at 3:01 AM, David Bruant wrote:
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with direct proxies and we have
On Sep 25, 2013, at 6:49 AM, Mark S. Miller wrote:
Why does Date need private state? AFAICT, it only needs uniquely named state.
Why not do what we've done for many other bits of internal state that doesn't
need to be private: just name it with a unique symbol? This doesn't work for
all
On Sep 24, 2013, at 9:59 PM, Erik Arvidsson wrote:
My concern is similar to Anne's. codePointAt will most likely not give
the right behavior and I'm concerned adding this without working
raising the bar significantly.
Since this is already implementable in ES3 I don't see why we should
On Sep 25, 2013, at 1:26 AM, Tom Van Cutsem wrote:
I recall that Allen and I had previously agreed that it would be cleanest if
each of the [[internal]] methods on Object would correspond 1-to-1 to a trap
in the Proxy API (and I believe this is the case for the current ES6 draft).
So my
At last weeks TC39 meeting we had consensus that the value of the @@unscopable
property should be a Set
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/sept-17.md#53-unscopeable
As I begin to look at implementing this (and the other @@unscopable changes
from the meeting) I'm
So here is another concern, about the scheme we agreed to last week.
It needs to match a found own property against the possibility of an own
@@unscopable property on the same object and that object may be somewhere up
the inheritance chain of the actual with object. The means that
On Sep 25, 2013, at 3:02 PM, Jason Orendorff wrote:
Suppose I have:
p onclick=alert('hello')
This creates new object environment records. (See the HTML spec, When
an event handler content attribute is set, step 6:
On Sep 23, 2013, at 12:05 PM, Oliver Hunt wrote:
I am reading the spec and it looks (to me at least) like we expect [a,b,c] +=
[1,2,3] to be equivalent to a+=1; b+=2; c+=3 — is that correct or have i
misread something?
No, see
On Sep 24, 2013, at 8:13 AM, Jason Orendorff wrote:
On Tue, Sep 24, 2013 at 7:23 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
[forking from [[invoke]]-thread for clarity]
Thanks!
Allen: would the removal of the hasOwn() trap imply that we can drop the
[[HasOwnProperty]] internal method
On Sep 24, 2013, at 7:37 AM, Mark S. Miller wrote:
Thanks to André and Tom, I think I now understand the problem. I think the
only solution lies in this comment from Tom:
On Tue, Sep 24, 2013 at 1:23 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
[...] The generic solution is membranes.
On Sep 24, 2013, at 10:18 AM, Mark Miller wrote:
One bit of data: A google search on uncurryThis says it gives 21,500
results. We should expect that many uses of this and similar patterns do not
use it by this name, so this should be taken, in some sense[1], as a lower
bound indication of
On Sep 24, 2013, at 10:06 AM, Mark S. Miller wrote:
I do not know and I do not know what to search on to find out. However, I
would guess it is used enough to be a real concern. We documented it at
http://wiki.ecmascript.org/doku.php?id=conventions:safe_meta_programming
for reasons that
On Sep 24, 2013, at 11:46 AM, Oliver Hunt wrote:
I'll try to rephrase:
As I read the spec this is not a syntax error, and so gets delayed to
runtime. Given that we're already doing work to determine whether we should
be destructuring (which results in different runtime semantics), it
On Sep 24, 2013, at 11:50 AM, Brendan Eich wrote:
Brandon Benvie mailto:bben...@mozilla.com
September 24, 2013 11:44 AM
It seems unfortunate that we have to rely on a membrane for something as
simply as `new Proxy(new Date, {}).getDate()` to work. [[Invoke]] as
currently specced gets
On Sep 24, 2013, at 12:15 PM, André Bargull wrote:
On Sep 24, 2013, at 8:13 AM, Jason Orendorff wrote:
On Tue, Sep 24, 2013 at 7:23 AM, Tom Van Cutsem tomvc.be at gmail.com
wrote:
[forking from [[invoke]]-thread for clarity]
Thanks!
Allen: would the removal of the hasOwn()
On Sep 24, 2013, at 4:12 PM, Brendan Eich wrote:
Rick Waldron wrote:
- Normalize CR, LF, and CRLF to LF
[WH: Is this consensus recorded correctly? I understood the consensus to be
normalizing all lexical grammar LineTerminatorSequences to LF.]
TC39 members (including me) tend to forget,
On Sep 23, 2013, at 1:29 AM, Tom Van Cutsem wrote:
2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com
...
More concretely, existing code expects that
obj.valueOf()
is equivalent to
obj.valueOf.call()
but if obj is a transparent forwarding proxy on a map instance (or most
On Sep 23, 2013, at 1:33 AM, Tom Van Cutsem wrote:
2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com
...
c) double-lifting needs 2 traps (get + invoke) rather than just get.
I don't think so, using [[invokeFunction]] instead of [[Invoke]] eliminates
the need for two:
the current
On Sep 23, 2013, at 12:53 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I'm actually more concerned about inconsistent behavior for both internal
(eg, valueOf) and user coded conditional calls.
Why? Lots of traps have to be implemented consistently, why is any invoke
used
On Sep 23, 2013, at 3:50 PM, Brendan Eich wrote:
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 23, 2013 3:06 PM
It's a matter of internal vs external consistency. The implementor of a
Proxy handler needs to internally consistently implement the 'get', 'set',
'has', 'invoke
On Sep 23, 2013, at 6:14 PM, Kevin Smith wrote:
Hi Allen,
Your line of thinking has convinced me that `invoke` as it currently stands
doesn't really fly. However, I have an issue with your proposal. Take this
fragment:
(1) function f() { doSomethingWith(this); }
(2)
On Sep 23, 2013, at 6:32 PM, Allen Wirfs-Brock wrote:
On Sep 23, 2013, at 6:14 PM, Kevin Smith wrote:
Hi Allen,
Your line of thinking has convinced me that `invoke` as it currently stands
doesn't really fly. However, I have an issue with your proposal. Take this
fragment:
(1
Sorry, I meant obj's handler
Mark S. Miller erig...@google.com wrote:
What does f's handler refer to? If obj is a proxy and f is not, then obj has
a proxy and f does not.
On Mon, Sep 23, 2013 at 6:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 23, 2013, at 6:14 PM, Kevin
On Sep 21, 2013, at 2:51 AM, Tom Van Cutsem wrote:
2013/9/20 Allen Wirfs-Brock al...@wirfs-brock.com
BTW, I would want to use [[InvokeFunction]] for both directly obj.method()
and in the internals of F.p.call/apply
As I mentioned to your reply at the time, I believe the latter would
On Sep 21, 2013, at 2:53 AM, Tom Van Cutsem wrote:
2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com
On Sep 20, 2013, at 5:31 PM, Brendan Eich wrote:
Given this, having the legacy internal calls continue to use get+call
seems fine to me. A proxy implementing toString, e.g., can make
the paramaterized [[Invoke]] solution
On Jul 30, 2013, at 10:11 AM, Allen Wirfs-Brock wrote:
I wonder if we could respecify F.p.call/apply in a manner that would make
David's getMonth.call use case work (at least some of the time).
[[Invoke]](P, ArgumentsList, Receiver) is current specified such that P
On Sep 20, 2013, at 1:53 PM, Jason Orendorff wrote:
...
(I see [[Invoke]] as a regression too. Till and Allen’s latest
approach isn’t bad, but it still seems insufficiently motivated.)
The main reason I'm still supportive of [[Invoke]] (possibly with the option of
passing a function instead
On Sep 20, 2013, at 4:27 PM, Brandon Benvie wrote:
On 9/20/2013 12:19 PM, Jason Orendorff wrote:
what's the justification for .hasOwn()?
a) allows more direct interception of Object.prototype.hasOwnProperty()
b) potentially less allocations each time someone calls .hasOwnProperty().
I
On Sep 20, 2013, at 5:31 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The main reason I'm still supportive of [[Invoke]] (possibly with the option
of passing a function instead of a property key) is because it allows (and
that I think you pointed out) a proxy to implements some or all
On Sep 19, 2013, at 8:05 AM, Brendan Eich wrote:
Tom Van Cutsem mailto:tomvc...@gmail.com
September 19, 2013 9:53 AM
2013/9/19 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I really don't think we need to debate this much longer. We just
need to stay
On Sep 19, 2013, at 8:25 AM, Tom Van Cutsem wrote:
2013/9/19 Brendan Eich bren...@mozilla.com
Refactoring [[Get]]+[[Call]] to [[Get]]+[[Invoke]] seems fine by me. It
better expresses the intent, and the change should only be observable to
proxies.
Is this so? Wouldn't an ordinary object
On Sep 17, 2013, at 9:36 AM, Jason Orendorff wrote:
On Fri, Sep 13, 2013 at 11:36 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
MarkM and I talked about conditional invocation offline and we convinced
ourselves to argue for the status-quo (i.e. continue to encode conditional
invocations as
Also see https://people.mozilla.org/~jorendorff/es6-draft.html#sec-B.3.2
It still has some issues I need to work, put it's my starting point.
Allen
Brendan Eich bren...@mozilla.com wrote:
See
https://mail.mozilla.org/pipermail/es-discuss/2013-February/028632.html,
find 3c. Absolute minimum
On Sep 12, 2013, at 6:35 AM, Mark S. Miller wrote:
On Thu, Sep 12, 2013 at 4:14 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
[+markm, allenwb]
2013/9/11 David Bruant bruan...@gmail.com
Le 11/09/2013 16:22, Tom Van Cutsem a écrit :
[[GetInheritance]] always checks whether the proxy and
On Sep 12, 2013, at 12:45 PM, Oliver Hunt wrote:
On Sep 12, 2013, at 12:40 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
Just as a worked example, answering Oliver's question about default
expressions took me the better part of an hour.
The default-expression h() in code like
On Sep 12, 2013, at 12:40 PM, Jason Orendorff wrote:
Just as a worked example, answering Oliver's question about default
expressions took me the better part of an hour.
The default-expression h() in code like
function f(x=h(), y) {
function h() { ... }
}
is evaluated in
On Sep 11, 2013, at 8:53 AM, David Bruant wrote:
Le 11/09/2013 17:51, Allen Wirfs-Brock a écrit :
Ps: btw, wasn't GetInheritance supposed to be renamed GetPrototype?
I think we had agreement on that. Allen?
I'm willing to call them [[GetPrototypeOf]] and [[SetPrototypeOf]] to match
On Sep 11, 2013, at 7:17 AM, Tom Van Cutsem wrote:
2013/9/11 David Bruant bruan...@gmail.com
Le 11/09/2013 06:10, Boris Zbarsky a écrit :
Hey all,
I was looking at implementing a membrane using ES6 proxies and ran into a
snag. Consider a situation where object A has prototype B. A'
On Sep 11, 2013, at 11:02 AM, Brendan Eich wrote:
Tom Van Cutsem mailto:tomvc...@gmail.com
September 11, 2013 7:08 AM
1) The [[Invoke]] operation is meant to primarily trap method calls
generated by user-code of the form |obj.m(...args)|. This is by far the most
common case, and I believe
On Sep 11, 2013, at 3:07 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
1) The [[Invoke]] operation is meant to primarily trap method calls
generated by user-code of the form |obj.m(...args)|. This is by far the
most common case, and I believe we should not extend [[Invoke
Thanks, for the great feedback.
Annex F was my own attempt and keeping track of all the algorithms, but I out
grew it and it's too much trouble to manually keep it up to date while things
are still in flux. The other tension I've run into between easy identification
ia section numbers and a
On Sep 11, 2013, at 5:13 PM, Brendan Eich wrote:
Jason Orendorff mailto:jason.orendo...@gmail.com
September 11, 2013 3:38 PM
But as Allen said, [[Invoke]] is not a performance hack. It's a
correctness hack.
It permits proxies to customize their behavior around `this`, and even
naive
On Sep 11, 2013, at 6:30 PM, Waldemar Horwat wrote:
On 09/11/2013 03:38 PM, Jason Orendorff wrote:
On Wed, Sep 11, 2013 at 9:08 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Currently the pattern for this is [[Get]]+[[Call]]. We cannot refactor to
[[Has]] + [[Invoke]] in general, because
On Sep 10, 2013, at 3:55 AM, Till Schneidereit wrote:
When implementing the [[Invoke]] trap in SpiderMonkey, I went with the
assumption that it should apply to all calls of the forms `receiver.fun()`
and `receiver[fun]()`. Jason pointed out that `with (receiver) { fun() }`
should be
On Sep 10, 2013, at 5:15 AM, Till Schneidereit wrote:
On Tue, Sep 10, 2013 at 1:31 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Note that determining desired pattern is relevant to the new DOM promises
design (tracking this at
On Sep 10, 2013, at 8:20 AM, Jason Orendorff wrote:
On Tue, Sep 10, 2013 at 6:31 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Note that determining desired pattern is relevant to the new DOM promises
design (tracking this at
On Sep 10, 2013, at 10:37 AM, Andrea Giammarchi wrote:
AFAIK 99% of libraries out there believe that slice.call will return an Array
of the current realm.
Can you explain why the Realm makes a difference to them? Is it because they
are doing instanceof Array tests rather than
On Sep 10, 2013, at 11:12 AM, Andrea Giammarchi wrote:
As short answer, let me reformulate:
AFAIK 99% of libraries out there believe that slice.call will return an
Array, no matter which realm. In ES6 I see there's too much magic involved
because of subclassing possibility.
Presumably
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 9, 2013 2:50 PM
On Sep 9, 2013, at 2:37 PM, Jason Orendorff wrote:
There are some places
On Sep 10, 2013, at 12:14 AM, Mathias Bynens wrote:
FWIW, here’s a real-world example of a case where this behavior is
annoying/unexpected to developers: http://cirw.in/blog/node-unicode
This suggests to me that the problem is in JSON.stringify's Quote operation. I
can see an argument that
On Sep 10, 2013, at 3:24 PM, Rick Waldron wrote:
On Tue, Sep 10, 2013 at 1:37 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I see one of two problems mentioned in my other topic is already discussed
here so I'd like to add this question that will most likely break the web:
On Sep 10, 2013, at 10:48 AM, Till Schneidereit wrote:
Wasn't a major point in favor of having an [[Invoke]] trap that it wouldn't
require returning a function from the trap at all? We'd lose this quality
with both of these proposals.
No, the major motivation was to provide a way to deal
On Sep 10, 2013, at 10:45 AM, Jason Orendorff wrote:
On Tue, Sep 10, 2013 at 11:11 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Having to create a new bound function on every method call seems too
expensive.
Only for proxy method calls, and it's easily optimized away
On Sep 10, 2013, at 4:11 PM, Andrea Giammarchi wrote:
Rick I think I've often seen this which is not that naive accordingly with ES
5.1 down to ES 3 specs, IMO .. it worked with DOM, arguments, and everything
with a `length` till now.
```javascript
On Sep 10, 2013, at 4:38 PM, Andrea Giammarchi wrote:
right now? the `[[Class]]` such as `'[object Array]'` ... and the magic is
this smarter slice.
And what does [[Class]] == Array actually tell you? Primarily that the Array
length invariant is automatic enforced.
You seems to be
901 - 1000 of 2846 matches
Mail list logo
