Hi,
I was looking at Bugzilla and came across two bugs [1] [2] related to
Mootools-based (only Mootools 1.2-) websites being broken by the inclusion
of String.prototype.contains in SpiderMonkey.
I don't think it's been brought to the list yet, though I think it's
relevant.
David
[1]
Hi,
Firefox has implement a Map/Set.prototype.size *method* to query the number
of mapping/elements.
It's not in the strawman. It appears in the latest draft, though weirdly
enough Map.prototype.size is a function with an unused argument.
What about making it an getter instead of a function? I
2012/10/11 Andreas Rossberg rossb...@google.com
On 11 October 2012 09:32, Brendan Eich bren...@mozilla.org wrote:
Tom Van Cutsem wrote:
- Proxy.revocable returns a tuple {proxy, revoke}. While more cumbersome
to work with (especially in pre-ES6 code without destructuring), this
API
2012/10/10 David Bruant bruan...@gmail.com
About making the restriction for membranes official could be done by
introducing branded proxies which output values (through
get/getOwnPropertyDescriptor/getPrototypeOf... traps) would also be
branded proxies (with the same brand). Brand validation
Hi,
I've tried the following on Firefox:
function f(a, b = 34, c){
console.log('b', b)
}
f(1, undefined, 43)
and got Exception: parameter(s) with default followed by parameter without
default
It seems intentional, but I wonder why it's been decided this way.
It seems that default
2012/10/10 Keith Cirkel es-disc...@keithcirkel.co.uk
You /are/ actually passing in a second argument though, your second
argument is `undefined`. Default arguments aren't meant to replace
`undefined` values, they're meant to be permissible for omission.
From
2012/10/10 Tom Van Cutsem tomvc...@gmail.com
2012/10/10 David Bruant bruan...@gmail.com
Having this uniqueness invariant is what enforces graph isomorphism. In a
nutshell, unlike the current proposal, traps can still return proxies, but
it has to be the exact proxy that can be returned
[I re-ordered a bit your message before answering]
2012/10/8 Tom Van Cutsem tomvc...@gmail.com
Hi David,
I really don't think this is an elephant in the room.
It's reassuring, I was somewhat shocked by the thought something like this
could have been overlooked :-p
Finally, note that a
2012/10/9 Tom Van Cutsem tomvc...@gmail.com
[+markm]
2012/10/9 David Bruant bruan...@gmail.com
Within a membrane, the following object-identity equailty is broken:
Object.getPrototypeOf(new wrappedC) !== wrappedC.prototype.constructor
(either because the operation throws or the returned
Le 09/10/2012 19:52, Mark S. Miller a écrit :
On Tue, Oct 9, 2012 at 6:25 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
My point is that if the trap returns something else than the
original object, a defender who knows which object is expected can
know
Hi,
Proxies enable the implementation of membranes [1]. It's one motivating use
case of proxies. Useful membranes mediate access to every object which was
reach from another object in the membrane.
I realize now that Object.getPrototypeOf violate this principle in harmful
ways:
function
Hi,
In the latest spec draft, the [[Enumerate]] internal operation has an
includePrototype argument (it also has an onlyEnumerable argument, but
that's irrelevant to my point). for..in loops use [[Enumerate]]
with includePrototype true and Object.keys/getOwnPropertyNames use
[[Enumerate]] with
I think there is an idea which hasn't been mentionned yet which would be
to let programmers merge or assimilate cross-frame symbols.
Basically, when receiving a symbol from some frame, it'd be possible to
say I assimilate this symbol I received from another frame to my own
persistableSymble.
I
Le 06/10/2012 19:52, Allen Wirfs-Brock a écrit :
(...)
Either of these use cases seem like something that should be easily
accomplished, if you are defining the module loaders that set up the
frames and control module loading into the frames.
True. That may be a good idea to think about it
Le 05/10/2012 15:05, Tom Van Cutsem a écrit :
2012/10/4 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
I think the invariant should be:
ToBoolean(definePropertyTrapOutput) === true
= (descArgument.configurable === targetDesc.configurable)
I would formulate
Le 05/10/2012 17:23, Mark S. Miller a écrit :
On Fri, Oct 5, 2012 at 7:11 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
mailto:sa...@ccs.neu.edu wrote:
Note also that `Symbol.for` has some really weird behavior. For
example, what does this evaluate to?
Symbol.for(x) instanceof
2012/10/4 Brendan Eich bren...@mozilla.org
David Bruant wrote:
Unforgeability can be given up, but you end up with global namespaces.
new Symbol(21fef4ae-1439-4b6a-**b412-3585906b35f1); or
org.ecmascript.system.**iterator
This is no better than dunder-iterator (I mean '__iterator__', I
Hi,
I think it's the dual of the getOwnPropertyDescriptor invariant I talked
about recently.
var t = {a:1};
var p = new Proxy(t, {
defineProperty: function(target, name, desc){
return true; // pretend it's always successful
}
});
Object.defineProperty(p, 'a',
Hi,
Currently, the wiki says:
Invariant check: check whether the target’s prototype and the trap result
are identical.
If the trap can only report one value, there is almost no point in having a
trap.
A getPrototypeOf trap allows for proxies to potentially simulate __proto__
in a platform where
2012/10/4 Mark S. Miller erig...@google.com
On Thu, Oct 4, 2012 at 4:36 AM, David Bruant bruan...@gmail.com wrote:
Hi,
Currently, the wiki says:
Invariant check: check whether the target’s prototype and the trap
result are identical.
If the trap can only report one value
Le 04/10/2012 20:35, Mark S. Miller a écrit :
On Thu, Oct 4, 2012 at 8:40 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
* It allows the target to be modified first, in anticipation
of the target being queried at the end of the trap.
Do we really
Le 04/10/2012 22:01, Mark S. Miller a écrit :
If the extensible proxy has no access to the original
Object.prototype.__proto__, then it cannot modify the [[Prototype]] of
its target, and so should not be able to seem to have its own mutable
[[Prototype]]
Ok, so the rationale behind the
Le 03/10/2012 18:37, Nicholas C. Zakas a écrit :
(...)
Set.prototype.toJSON = function() {
return Array.from(this);
};
That way, JSON.stringify() would do something rational by default when
used with sets.
Thoughts?
Useful defaults. I love it!
David
Le 03/10/2012 21:01, Brendan Eich a écrit :
Thanks for pointing this out. Python's dunder-prefixing or anything
like it in JS has that advantage: you can spell the magic property
name with a string that works in any frame or global object. Of course
strings can collide.
Symbols are useful in
Le 03/10/2012 23:09, Brendan Eich a écrit :
Domenic Denicola wrote:
Would it suffice to allow cross-frame sharing of symbols via
postMessage and its structured clone algorithm? They're immutable,
right?
They are immutable but you'd still have to pass your @iterator to
another same-origin
2012/10/2 Mark S. Miller erig...@google.com
On Mon, Oct 1, 2012 at 9:02 PM, Brendan Eich bren...@mozilla.com wrote:
Words on paper still carry force but they do not necessarily have prompt
effects, or any effects. It depends on the people reading them and
implementing, and trying to follow
Hi,
If I'm following properly, iterate is now a unique name that can be used on
any object as per July 24 meeting notes [1]. It led the decision to remove
the iterate trap on proxies [2]:
Removed ''iterate()'' trap as iterators can be defined on any old object
via an ''iterate'' unique name. See
s/name/symbol, obviously :-)
2012/10/1 David Bruant bruan...@gmail.com
Hi,
If I'm following properly, iterate is now a unique name that can be used
on any object as per July 24 meeting notes [1]. It led the decision to
remove the iterate trap on proxies [2]:
Removed ''iterate()'' trap
Hi,
Re-forking a bit to discuss not the output of typeof aSymbol, but rather
the spec type (like ES5.1 - 8.x sections) of symbols.
Although we can discuss whether typeof should return object, it's clear
to me that symbols aren't quite Objects (as per ES5.1 - 8.6). So far, they
have no reason to
Le 01/10/2012 21:42, Brendan Eich a écrit :
Andreas Rossberg wrote:
On 30 September 2012 00:08, Brendan Eichbren...@mozilla.org wrote:
I think this is too philosophical a discussion to result in a strong
reason
to risk symbol. Just my gut-check. Other TC39ers should weigh in
(Andreas
R.
Thanks Rick for the notes (and everyone who contributed, I see several
colors)
Le 28/09/2012 03:00, Rick Waldron a écrit :
# Proxy
(Presented by Tom Van Cutsem, Free University of Brussels)
## Revokable Proxies
(...)
Question as to whether we really need two kinds of proxies.
BE: yes,
Le 28/09/2012 17:31, Rick Waldron a écrit :
Ugh, sorry about that. I had a momentary brain melt and forgot to
unformat before sending
Ahah, don't worry about it :-)
David
___
es-discuss mailing list
es-discuss@mozilla.org
Le 28/09/2012 18:28, Tom Van Cutsem a écrit :
Discussion about whether revokable proxies introduce new ways for
interceptable operations to behave.
WH: Not sure about this as a feature, w/r to future hostility…
- eg. if === would trap to the handler how does this work with
Le 28/09/2012 19:56, Brendan Eich a écrit :
David Bruant wrote:
This point started with an what if typeof/=== is trappable?. If
it's sure that it never becomes trappable, everything's good.
I meant If it's sure that *they* (typeof/===) never become trappable,
everything's good (in the sense
...this is how I discovered that, in non-strict mode, it's possible to
define a function where 2 arguments have the same name...
Le 27/09/2012 18:19, Allen Wirfs-Brock a écrit :
Consider
function f(a, b=a, a=3, c=a) {
The most positive adjective I can find to describe this like is:
Le 27/09/2012 18:41, Allen Wirfs-Brock a écrit :
On Sep 27, 2012, at 9:31 AM, Andrea Giammarchi wrote:
it would be stupid to code like that but it makes sense since it has
basically always been like that :)
A big part of of my job is specifying what stupid code does.
I'm begging, please
[cc'ing Eddy Bruel for his opinion. Search for your name below]
Le 26/09/2012 20:46, Tom Van Cutsem a écrit :
2012/9/25 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
In this last paragraph, I've demonstrated a way for the whitelist
to be
a proxy to a weakmap without
Le 25/09/2012 07:49, Tom Van Cutsem a écrit :
2012/9/25 Waldemar Horwat walde...@google.com
mailto:walde...@google.com
Yes. This was bothering me during the meeting and (as far as I
know) didn't get resolved. What if someone passes in a proxy to a
WeakSet instead of an actual
Le 25/09/2012 02:05, P Horwat a écrit :
On 09/24/2012 01:24 AM, David Bruant wrote:
Le 24/09/2012 10:04, Tom Van Cutsem a écrit :
Right. Perhaps what Herby meant is that the proxy might provide a
malicious whitelist to steal the names being looked up in them. This
will be prevented
Le 25/09/2012 12:41, Andrea Giammarchi a écrit :
OT: Really David ... you use a french keyboard too?
guilty :-D
I can't imagine me programming with an italian layout :D
I think it's just a matter of habit. Regardless, I use WebStorm as text
editor, I think most of my code is written thanks to
Le 24/09/2012 10:04, Tom Van Cutsem a écrit :
2012/9/24 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 23/09/2012 22:04, Herby Vojčík a écrit :
Hello,
maybe I missed something, but how will you secure the whitelist
itself? Malicious proxy knowing
Le 24/09/2012 14:43, Jussi Kalliokoski a écrit :
Hello everyone,
I've been thinking a lot about parallel processing in the context of
JavaScript, and this is really a hard problem. I'm very curious to
hear what everyone's opinions are about it's problems and so forth,
but I don't think an
Le 24/09/2012 16:39, Dean Landolt a écrit :
s/shared state/shared *mutable* state/
True, I took it as granted, since objects are by default (very) mutable
in JavaScript.
___
es-discuss mailing list
es-discuss@mozilla.org
Hi,
In the current state of the strawman [1], one security invariants for
getOwnPropertyDescriptor is:
if property exists on target, check if the returned descriptor is
compatible.
I just wish to say on the list that it means that the following case throws:
var p = new Proxy({a:1}, {
Le 19/09/2012 13:48, Jason Orendorff a écrit :
On Wed, Sep 19, 2012 at 4:44 AM, David Bruant bruan...@gmail.com wrote:
Also, the wiki doesn't say how the check is being performed.
http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec
TrapGetOwnProperty specifies how the check
Le 18/09/2012 10:44, Tab Atkins Jr. a écrit :
On Tue, Sep 18, 2012 at 10:12 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
I wrote up a strawman that summarizes the discussion on proxies private
names in this thread:
http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names
There are still
Hi,
I'm talking about
http://wiki.ecmascript.org/doku.php?id=harmony:proto_climbing_refactoring#refactoring_hasproperty
The 2 first steps of the proposed algorithms are:
1. Let prop be the result of calling the [[GetOwnProperty]] internal
method of O with property name P.
2. If prop is not
Le 12/09/2012 08:19, Tom Van Cutsem a écrit :
2012/9/11 Mark S. Miller erig...@google.com mailto:erig...@google.com
[...]
If we change this API from returning an array of strings to
returning an iterator, I agree that alters the balance and
justifies waiving this particular
Le 11/09/2012 21:14, Tom Van Cutsem a écrit :
(...)
Note that in ES6, Reflect should probably be represented as a module
instance, not as a global object. So then Handler.prototype would
inherit from a module instance object. I don't see anything
necessarily wrong with that, but I just want
Le 11/09/2012 21:37, Tom Van Cutsem a écrit :
The enumerate() trap predates the TC39 blessing of iterators, but IIRC
we did agree to revisit its signature once iterators were in. I think
having the enumerate() trap return an iterator is perfectly sensible.
There's a catch, however:
As
Le 02/09/2012 23:13, Brandon Benvie a écrit :
The use of the term receiver is somewhat misleading when put next to
the receiver in the get and set traps. For get and set the receiver is
always the proxy unless it's an object that has the proxy as its
[[prototype]]. For function invocation the
Hi,
In the proxy proposal, one can read the following signature for the
apply trap:
apply: function(target,receiver,args) - any
But the receiver doesn't make much sense to me. Is it just a typo or
am I missing something?
David
[1] http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies
Hi,
The enumerate (for..in loops) and iterate (for..of loops) traps have
inconsistent signatures. The former needs an array of strings to be
returns, the latter an iterator.
I would tend to be in favor of both returning an iterator to avoid
allocating, filling freeing memory in case of
Le 02/09/2012 20:38, Rick Waldron a écrit :
On Sun, Sep 2, 2012 at 1:57 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
In the proxy proposal, one can read the following signature for the
apply trap:
apply: function(target,receiver,args) - any
Hi,
Direct proxies landed in Firefox a couple of days ago, so I thought I'd
rewrite every sample I had written to the new API.
I have started with the emulation of native arrays with proxies (and
normal objects) [1]. Most of my tests related to the proxyArray length
fail because I only override
Le 28/08/2012 15:38, Kevin Smith a écrit :
Apologies in advance for the length...
Don't. We're here to discuss as the mailing-list name suggests. And if
what you need to say is long, so be it.
A huge share of this complexity has been removed in recent
discussions [1]. Conclusions
Le 27/08/2012 15:34, Matthew Robb a écrit :
I'm trying to determine whether when compiling into ES3/5 you could
get away with not attaching some .__privates__ property to the object
and instead just put a closure around the definitions.
For that question, the answer is you cannot. You cannot
Hi Matthew,
Sorry, I mislead you. Let me retry:
class myClass{
private test;
constructor(){
this[test] = 0;
}
getTest(){return this[test]};
}
desugars to:
var myClass = (function(){
var test = new Name();
function
Le 27/08/2012 19:54, Matthew Robb a écrit :
I know this has some serious ugly to it but in the spirit of knowing
what COULD potentially create the expected behavior, would this not do
the trick?
var myClass = (function(){
function myClass(){
var __priv =
Le 27/08/2012 21:22, Kevin Smith a écrit :
A last alternative is to associate private data via a WeakMap (it
can be shimmed in ES5 with the same garbage collection properties
and with good performances) that inherited functions all have
access to. It works, but it's burdensome
Le 19/08/2012 09:40, Andrea Giammarchi a écrit :
The Object owner is a bit inconsistent concept in JS + DOM world.
No and yes, but no when one is careful.
The piece of code that creates an object can be considered as its owner.
If some code accesses an object only if it's given a reference to
Le 17/08/2012 16:11, Brendan Eich a écrit :
David Bruant wrote:
Could what I just described implemented with value proxies? I'm not
very familiar with the proposal.
See http://disnetdev.com/talks/virtual_values.pdf and
http://users.soe.ucsc.edu/~cormac/papers/oopsla11.pdf -- and probably
Interesting topic.
I'd like to share some experience and thoughts which are complementary
and may influence the proposal.
I've been playing with promises with some time and the way errors are
taken care offers different opportunities than normal error handling.
When using promises (I used
Le 16/08/2012 04:40, Allen Wirfs-Brock a écrit :
On Aug 15, 2012, at 5:09 PM, David Bruant wrote:
Le 14/08/2012 04:16, Allen Wirfs-Brock a écrit :
check out the current ES66 spec. draft. Based upon discussions at the
March TC39 meeting hypot2 was eliminated and an optional third
argument
Le 16/08/2012 03:11, Erik Reppen a écrit :
Well I went a bit long as I tend to when geeking out on stuff but I
think the topic of how these elements of the language could be used
better moving forward if we're stuck with 'em is interesting. I really
do find it's helpful in debug to have
What about high resolution time?
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html
David
Le 16/08/2012 13:42, Andrea Giammarchi a écrit :
Quick one, since I have discovered this only recently via
Object.keys(this) in JSC ( JavaScriptCore )
double =
Le 16/08/2012 14:02, Andrea Giammarchi a écrit :
looks like the result would be the same obtained via preciseTime() *
100 ... I just wonder why this is a W3C draft rather than a
ECMAScript one.
Same question stands for setTimeout/setInterval, setImmediate,
WebWorkers or the crypto API to
Le 15/08/2012 21:42, Rick Waldron a écrit :
Recently, Allen produced a strawman proposal[0][1] for the object
define properties operator, which was designed to provide syntax that
differentiated semantics of define vs. assign. Towards the end of the
thread, IIRC, Brendan suggested some new
Le 16/08/2012 00:35, Rick Waldron a écrit :
On Wed, Aug 15, 2012 at 6:02 PM, Erik Reppen erik.rep...@gmail.com
mailto:erik.rep...@gmail.com wrote:
Is consistent type return a heuristic carried over from more
strictly-typed paradigms or would it murder performance of the
Le 14/08/2012 04:16, Allen Wirfs-Brock a écrit :
check out the current ES66 spec. draft. Based upon discussions at the
March TC39 meeting hypot2 was eliminated and an optional third
argument as added to hypot.
Quoting relevant part of the March meeting notes [1]:
Discussion of hypot, hypot2.
Hi,
I'd like to provide some feedback on the more math functions proposal
[1] (and the most recent PDF at the top of the page)
The hypot and hypot2 functions accept 2 or 3 arguments, but I don't see
a reason why they wouldn't accept an unbounded number of arguments.
Although the physical
Le 13/08/2012 19:56, Christian Mayer a écrit :
Am 13.08.2012 11:16, schrieb David Bruant:
I'd like to talk about naming as well. hypot (for Hypotenuse) is an
accurate name for the 2 dimension case, but much less for 3 dimensions
as far as I know (the English wikipedia page [2] doesn't mention
Hi,
It's been a couple of days that this thread has had no update and
specifically no answer to Mark Miller's question Other than the
additional complexity, which is a significant argument against, what
other arguments are there against enabling a proxy to drop its target?
So I guess we can
Le 03/08/2012 17:45, David Bruant a écrit :
(...)
It reminded me of an ECMAScript Regret submitted by Tom about the fact
that method are extracted unbound by default.
And after a couple of tweets related to 'with' and the canvas API I
wonder: would it be worth having another syntactic form
Le 04/08/2012 17:53, Claus Reinke a écrit :
[argh, unhelpful hidden key-combo led to premature send]
But it also made me realize that by default, destructuring returns
unbound methods. It's perfect for the above use case, but may be
annoying when you wish to extract functions bound to the
Le 03/08/2012 04:03, Tom Van Cutsem a écrit :
Thanks for clarifying the Racket design, Sam.
I like the proposed refactoring where David's proposed
isPrivateNameKnown property essentially becomes an extra argument to
the Proxy constructor (let's call it the name whitelist).
(... until we call
Hi,
A code joke from a colleague [1] revealed [2] that
String.prototype.substr is not part of ES5.1 as normative.
Kangax tables indicate that this property is in all modern browsers [3].
I think it'd be worth moving this method to the normative part of the
spec and that tests be added to
Le 03/08/2012 12:46, Rick Waldron a écrit :
On Friday, August 3, 2012 at 12:24 PM, David Bruant wrote:
Hi,
A code joke from a colleague [1] revealed [2] that
String.prototype.substr is not part of ES5.1 as normative.
Kangax tables indicate that this property is in all modern browsers [3].
I
Le 03/08/2012 12:58, Allen Wirfs-Brock a écrit :
substr is in Annex B, which in ES5.1 is an informative annex. In ES6, the
content of Annex B will be optional normative. Required for web user agents,
but optional for other hosts.
Ok. Is it planned to extend ES6-test262 scope to include
Hi,
I spent a couple of hours presenting proxies to a couple of folks at the
IDRC (Inclusive Design Research Center) in Toronto and Colin Clark (IDRC
Tech Lead) made me realize that we have lost something between the
previous proxy design and the current one. This is related to the
caretaker
Le 03/08/2012 17:08, Sam Tobin-Hochstadt a écrit :
On Fri, Aug 3, 2012 at 5:03 PM, David Bruant bruan...@gmail.com wrote:
With the current design, there is no way to cut the access to the target and
enable its garbage collection because the target is an internal property of
the proxy. It means
Hi,
I wrote some code today:
var cos = Math.cos,
sin = Math.sin,
PI = Math.PI;
// later:
x1 = x + R*cos(t)*cos(angle) - r*sin(t)*sin(angle);
First of all, it made me realize that the usual example of 'with' (using
with(Math) and an expression like I showed) turn
Le 03/08/2012 17:38, Sam Tobin-Hochstadt a écrit :
On Fri, Aug 3, 2012 at 5:12 PM, David Bruant bruan...@gmail.com wrote:
Le 03/08/2012 17:08, Sam Tobin-Hochstadt a écrit :
On Fri, Aug 3, 2012 at 5:03 PM, David Bruant bruan...@gmail.com wrote:
With the current design, there is no way to cut
Le 03/08/2012 20:03, Brendan Eich a écrit :
I think I buy this *if* we spec WeakSet and require it (and only it,
not a trickster impersonator) as the optional third argument. And of
course it's a live set.
Alternative: take any arraylike and treat it as a descriptor, not
live, whose elements
Le 03/08/2012 19:54, Brendan Eich a écrit :
David Bruant wrote:
So your actual target can be GC'ed, but the dummyTarget has to keep
observed non-configurable (and non-writable) properties. Or you can
give up non-configurability.
I don't find any of these solutions satisfactory.
Please see
2012/8/2 Tom Van Cutsem tomvc...@gmail.com
[+samth]
2012/8/2 David Bruant bruan...@gmail.com
To follow-up on that part, here is a gist with the difference between
what the current proposal is and the alternative proposal [1]. [...]
[1] https://gist.github.com/**3232772 https
Le 02/08/2012 15:26, Sam Tobin-Hochstadt a écrit :
On Thu, Aug 2, 2012 at 2:00 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
[reordering a little]
Your observation that the value to be set leaks to a
setName/definePropertyByName trap is spot-on. It's indeed the dual of
protecting the return
Le 01/08/2012 00:05, Brendan Eich a écrit :
David Bruant wrote:
From a practical point of view, if 2 implementations differ on one
aspect of the language, it means that there is no content relying on
either of the 2 implementations for that aspect of the language,
whether they follow the spec
Le 01/08/2012 09:07, Tom Van Cutsem a écrit :
2012/7/31 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
2012/7/31 Tom Van Cutsem tomvc...@gmail.com
mailto:tomvc...@gmail.com
[...]
I think I missed the *Name trap design in the notes.
Returning [name, value
2012/8/1 Tom Van Cutsem tomvc...@gmail.com
2012/8/1 David Bruant bruan...@gmail.com
Le 01/08/2012 09:07, Tom Van Cutsem a écrit :
2012/7/31 David Bruant bruan...@gmail.com
[...]
Maybe the details I propose are not perfect, but I think there is a
game-changer in the idea of a handler
2012/7/31 Tom Van Cutsem tomvc...@gmail.com
2012/7/30 David Bruant bruan...@gmail.com
Le 28/07/2012 15:16, Tom Van Cutsem a écrit :
We still want proxies to intercept private names. It may be that the
proxy handler knows about the private name, in which case it has the
capability
]]/[[CanPut]] semantic issues:
On Jul 28, 2012, at 6:02 AM, David Bruant wrote:
Le 28/07/2012 14:37, Herby Vojčík a écrit :
...
:-/ But that is how it is, no?
That's what the spec says, but V8 has implemented something else (and I
haven't seen an intention to change this behavior), so what the spec
says
Le 28/07/2012 21:04, Allen Wirfs-Brock a écrit :
(...)
We introduce a new operator that is looks like :=
This is the define properties operator. Both the LHS and RHS must
be objects (or ToObject convertible). Its semantics is to
[[DefineOwnProperty]] on the LHS obj a property corresponding
// handler.hasInstance(targetFunction, x)
MM: Explains concerns originally raised on es-discuss list by David
Bruant, but shows the cap-leak is tolerable
I'm interested in the demonstration :-)
Mark acknowledged your concerns, but pointed out that currently almost
no capability
Hi,
First and foremost, thanks for the notes :-)
Le 28/07/2012 01:55, Rick Waldron a écrit :
Fix override mistake
# The can put check
(...)
Property in a prototype object that is read-only cannot be shadowed.
Just the same as get-only accessor.
I'd like to add a use case here. Every once
by David
Bruant, but shows the cap-leak is tolerable
I'm interested in the demonstration :-)
…
DH: if hasInstance private name on instanceof RHS...
MM: What Object.prototype does private name inherit from?
I assume s/Object.prototype/[[Prototype]], here?
AWB: Probably null
BE: the E4X any
Le 28/07/2012 13:43, Herby Vojčík a écrit :
David Bruant wrote:
var a = [];
a.push = function(elem){
if(condition(elem)){
// do something like change the elem value then do an
actual
push
// or throw an error
// or just ignore
Le 28/07/2012 14:37, Herby Vojčík a écrit :
David Bruant wrote:
Le 28/07/2012 13:43, Herby Vojčík a écrit :
David Bruant wrote:
var a = [];
a.push = function(elem){
if(condition(elem)){
// do something like change the elem value then do an
actual
push
Le 24/07/2012 17:40, Jussi Kalliokoski a écrit :
I would expect that since Error works without `new`, it would
disregard `this`, hence that call would just return a new Error, so:
Error.call(o, 'ya') instanceof Error // true
... true.
Error.call(o, 'ya').message === 'ya';
My bad.
David
Hi,
I'd like to announce to the list a project I have recently started:
https://github.com/DavidBruant/ECMAScript-regrets
Web technologies cannot be fixed because of backward compatibility
constraints. As an unfortunate consequence ugly things are meant to
stay. This is regrettable, we all know
601 - 700 of 1196 matches
Mail list logo
