Le 21/01/2013 10:05, Claude Pache a écrit :
Le 16 janv. 2013 à 09:11, David Bruant bruan...@gmail.com a écrit :
Hi,
This is an idea naturally derived of all the current discussions about WeakMaps
and Private symbols. The proposal is easily summarized by these lines of code:
var wm = new
Le 21/01/2013 11:58, David Bruant a écrit :
Before the clear method, weakmaps had the following property: you can
only modify a weakmap entry if you have the key. This property isn't
true anymore with .clear. This may be considered as abusive ambient
authority.
Let's see how this feature came
Le 21/01/2013 17:16, Rick Waldron a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
I think WeakMap.prototype.clear slipped through the crack without
being specifically discussed. Based on what's publicly available,
I don't
is the main reason to introduce, why not wait until
performance actually becomes a bottleneck? Something about premature
optimizations.
On Jan 21, 2013, at 3:04 AM, David Bruant wrote:
Le 21/01/2013 11:58, David Bruant a écrit :
Before the clear method, weakmaps had the following property
David
Thanks and have a nice day or evening
On Mon, Jan 21, 2013 at 8:16 AM, Rick Waldron waldron.r...@gmail.com
mailto:waldron.r...@gmail.com wrote:
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
I think
Le 21/01/2013 20:30, Brendan Eich a écrit :
David Bruant wrote:
I guess TC39 agrees on the Any new method added to one is going to
get added to all of them, unless
Why do you guess that?
I didn't see anything in the notes about discussions related
specifically to WeakMap.prototype.clear
Le 20/01/2013 06:36, Kevin Smith a écrit :
It is not. At the exit of the get trap, the JS engine checks
whether invariants should be enforced for the given property on
the target. In your case, the runtime sees that the target has a
non-configurable non-writable property called
Le 20/01/2013 16:49, Kevin Smith a écrit :
Got it. And one more (thanks for bearing with me)
I forked the thread. Go crazy if you have other questions :-)
what affect does throwing an error have within a trap?
You can think of it as an internal error, very much like
Object.defineProperty
Le 20/01/2013 18:59, Brendan Eich a écrit :
David Bruant wrote:
I disagree with Brendan when he says to use weakmaps for class
private instance methods/variables... well... it depends on what
use means:
The spec is allowed to /use/ anything it needs to make the class
private syntax work
Le 20/01/2013 18:54, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 3:04 AM, David Bruant wrote:
Le 20/01/2013 05:27, Allen Wirfs-Brock a écrit :
Weakmaps and symbol keyed properties (private or not) are very different
mechanism. They each have a variety of uses and differing
Le 20/01/2013 19:01, Brendan Eich a écrit :
David Bruant wrote:
Once again, the spec (well... you in that case :-) ) will do whatever
is necessary to make the feature understandable by spec readers.
Transpilers will work with whatever is in the language. If they only
have weakmaps, they'll use
Le 19/01/2013 16:30, Kevin Smith a écrit :
The interaction between private syntax and proxies has the
following components:
1) Do the proxy and the target act the same regarding private
properties?
The answer is yes with whitelisted private symbols, no with naive
Le 19/01/2013 19:04, Kevin Smith a écrit :
It calls the unknownPrivateSymbol trap. If the trap throws, the
operation fails. In all other cases (no trap or trap which doesn't
throw), it's forwarded.
And can frozen objects be proxy targets, or no?
Yes they can.
More generally,
Le 18/01/2013 06:47, Russell Leggett a écrit :
On Thu, Jan 17, 2013 at 9:40 PM, Kevin Smith khs4...@gmail.com
mailto:khs4...@gmail.com wrote:
It seems as if this approach to private class members also allows
us to describe private methods in a convenient way. Private
methods can
Le 18/01/2013 18:58, Rick Waldron a écrit :
It doesn't seem reasonable to maintain two versions of the proposals
as they become specifications.
My first thought is that the simplest possible strategy is to update
harmony proposal pages (on the wiki) with a line at the top that
indicates that
Hi Ladislav,
Le 18/01/2013 22:51, neuralll a écrit :
Hi guys
I am playing with web audio api and mozilla audio api but I got frustrated
about so much html5 potential wasted due to infinite codecs deadlock support in
browsers holding progress back for so long.
This even resulted to people
Le 17/01/2013 18:00, Mark S. Miller a écrit :
However, after the Private Slots thread, I spent a sleepless night
chewing on getting rid of private symbols.
Happens to me so often :-)
I now think we should.
Going back to my earlier
On Wed, Jan 16, 2013 at 12:37 PM, Mark S. Miller
Le 17/01/2013 19:30, Mark S. Miller a écrit :
On Thu, Jan 17, 2013 at 10:02 AM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 18:00, Mark S. Miller a écrit :
I still have this position on classes. But I no longer buy that
pessimistic conclusion about WeakMaps. Consider how WeakMaps
Le 16/01/2013 20:27, Brendan Eich a écrit :
David Bruant wrote:
Le 16/01/2013 19:42, Brendan Eich a écrit :
David Bruant wrote:
Hi,
This is an idea naturally derived of all the current discussions
about WeakMaps and Private symbols. The proposal is easily
summarized by these lines of code
Le 16/01/2013 21:19, Brendan Eich a écrit :
David Bruant wrote:
Am I misunderstanding how JIT compilation using type information works?
The problem is not just adding another deoptimization path. Not all
JITs use only PICs. Lots of optimizations are possible. But adding a
?: to the *generic
instance as its semantics naively suggests. So of the
options practically on the table, I think private symbols are the only
workable choice. If this is correct, then I consider private symbols
to be a requirement. Am I missing anything?
I agree, but David Bruant is arguing for weakmap-with-hint still
Le 14/01/2013 19:21, Claus Reinke a écrit :
From the teachability perspective, I'm tired of explaining the
closure hack to explain private properties. Even to some who are
experienced webdevs, I have to explain that they can't access the
private property through this..
The language needs to
Le 15/01/2013 06:53, Dmitry Soshnikov a écrit :
On Jan 14, 2013, at 9:32 PM, Dmitry Soshnikov wrote:
Hello,
Don't know whether it was mentioned/asked before (sorry if so), but just a
note: probably it makes more sense making the target argument as optional and
the second one in the Proxy
Hi Mark,
I have a couple of comments:
* On the share-nothing model
This comment goes beyond the paper, but I think is relevant for future work.
Practice of the event loop model in JavaScript has proven that the
share-nothing model has limitations. In my opinion, one of the reasons
WebWorkers
Le 15/01/2013 17:16, Kevin Smith a écrit :
The variable was called s standing for secret. The example I
gave was dummy, but examples in the wild are legion. Take your
favorite node library. Anytime it defines a _property, this is
where there should be a private name.
Again,
Le 15/01/2013 20:32, Tom Van Cutsem a écrit :
2013/1/10 Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com
David Bruant wrote:
[Cc'ing Tom and Mark to be sure there is agreement on what I'm
claiming in this message]
Le 10/01/2013 22:10, Brendan Eich
Le 15/01/2013 21:06, Herby Vojčík a écrit :
David Bruant wrote:
ES6 provides WeakMaps and Proxies. Why not see what people do with
those before introducing private slots?
I wouldn't be opposed to that, but that's just my opinion. Still,
private symbols allow property-like syntax. I haven't
Le 15/01/2013 19:19, Kevin Reid a écrit :
On Tue, Jan 15, 2013 at 2:20 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Practice of the event loop model in JavaScript has proven that the
share-nothing model has limitations. In my opinion, one of the
reasons
Le 14/01/2013 16:57, Kevin Smith a écrit :
When a property is added to an object using a private symbol, it
creates a new kind of slot: a private slot. It is clear from the
design of the Proxy API that this represents a fundamentally new
extension to the ES object model.
On the very first
Le 12/01/2013 21:58, Andrea Giammarchi a écrit :
that is a (quick/imperfect/asexample) way to detect a proxy while I
understand these should not be detectable.
{} and [] also return true to your test, but they're not proxies. You
cannot use an imperfect test to prove a point.
As I (and others
Le 12/01/2013 23:28, Andrea Giammarchi a écrit :
I don't want to detect node and proxied node
Why would you have to?
Currently, before calling .appendChild, do you write code that detects
that you're not trying to append a normal object or a date or an array?
I have personally never done such
Le 12/01/2013 23:54, Nathan Wall a écrit :
David Bruant wrote:
Leaking the information that the node is actually a proxy is due to a
DOM API issue (which is way way too late to fix obviously).
If you want proxied node to go in the tree, you'll need to find an
answer to the issue Boris Zbarsky
Le 13/01/2013 00:18, Brandon Benvie a écrit :
This isn't exactly a direct parallel because all the types that are
included as part of ES6 will be proxyable in such a way that the proxy
can be transparently interchanged with its target. The problem with
DOM objects is that this isn't true. I
Le 13/01/2013 00:09, Nathan Wall a écrit :
hmm.. I just realized that B doesn't have direct access to O. So even if B does
have access to M, trying to get N from P[M] would expose N to the membrane.
Yes and once the membrane has captured N, it has to search again if some
object use in A---B
Le dim. 13 janv. 2013 00:43:29 CET, Nathan Wall a écrit :
David Bruant wrote:
Yes and once the membrane has captured N, it has to search again if some
object use in A---B communication has an N property... and restart all
over if an object does and has another private name attached
Le 11/01/2013 06:46, Nathan Wall a écrit :
David Bruant wrote:
For the long term, I expected DOM objects could be proxified.
Boris convinced me otherwise for DOM Nodes at least.
Are you so convinced that the `unknownPrivateSymbol` trap is necessary?
I would think so, for instance, when one
Le 09/01/2013 23:57, Andrea Giammarchi a écrit :
do you have any example of what you are saying? all my examples fail
and I don't understand other use cases.
I don't. You seem to be relying a lot on the Firefox implementation, but
there are 2 things to be aware of as far as I know (sorry I
Le 10/01/2013 17:22, Nathan Wall a écrit :
Choosing symbols or a weakmap would make a huge difference in how proxy
replacement would react to DOM algorithms.
If the DOM in terms of accessing private properties, then proxies can
replace DOM objects transparently. Their unknownPrivateSymbol trap
Le 10/01/2013 17:41, Brendan Eich a écrit :
Nathan Wall wrote:
In the case of (1), the implementation using a private symbol will
have internal accesses to the `timestamp` symbol exposed through the
unknownPrivateSymbol trap.
Private symbols do not trap.
They do trap, but they don't leak.
[Cc'ing Tom and Mark to be sure there is agreement on what I'm claiming
in this message]
Le 10/01/2013 22:10, Brendan Eich a écrit :
Nathan Wall wrote:
Brendan Eich:
No, not if the symbol is not in the whitelist. Zero information
leak is
required.
That's good news too. Objection withdrawn.
Le 10/01/2013 22:31, Tab Atkins Jr. a écrit :
On Thu, Jan 10, 2013 at 1:24 PM, David Bruant bruan...@gmail.com wrote:
I think the return true/false protocol should be replaced by a return/throw
protocol (return value is ignored). It'd be much more explicit this way.
FWIW, I kinda like
Le 08/01/2013 22:59, Erik Arvidsson a écrit :
On Tue, Jan 8, 2013 at 4:46 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
One idea would be in the short term that implementations reliably
*always* throw when trying to wrap non-ECMAScript objects and play
Le 09/01/2013 06:57, Boris Zbarsky a écrit :
And specifically, it's not clear what the behavior should be when
there are two different scripted proxies for the same WebIDL object.
Say it's a DOM node. One of the proxies gets passed to appendChild.
When later getting that node out of the DOM
Le 31/12/2012 13:43, Tom Van Cutsem a écrit :
Hi David,
I generally support this view, although it may be too restrictive to
completely disallow non-standard exotics.
Instead, I would be happy if we could just state that non-standard
exotics are expected to uphold the invariants of the ES6
Le 09/01/2013 14:55, Andrea Giammarchi a écrit :
all this reminds me, hilariously, the Object.defineProperty case in
Internet Explorer 8 ... the infamous implementation that works only on
global and DOM objects. Here we have the opposite behavior, something
so powerful that could let us
Le 08/01/2013 22:23, Tab Atkins Jr. a écrit :
Meanwhile, there is unforgeable magic
behind DOM objects, and nothing we can really do about it.
Do you have examples? Besides document.all being falsy, everything seem
to be emulable with ES6 proxies.
David
Le 09/01/2013 16:02, Boris Zbarsky a écrit :
On 1/9/13 5:24 AM, David Bruant wrote:
When later getting that node out of the DOM with .firstChild, what
should be handed back? The proxy that was passed in, the JS object
that proxy was wrapping, something else (e.g. an exception is thrown
Le 09/01/2013 19:43, Boris Zbarsky a écrit :
On 1/9/13 1:23 PM, David Bruant wrote:
What happens if unknownPrivateSymbol throws?
I'm not sure yet. My guess is that the error should be propagated
So just to make sure we're on the same page here... Say I have a
proxy for a div and I put
Le 09/01/2013 20:30, Allen Wirfs-Brock a écrit :
David seems to be primarily concerned about people who are writing specs. for
non-standard exotic objects (eg, W3C/WebIDL-based spec. writers) rather than
implementors of such objects.
I am indeed. When there is a spec, implementors only have
Le 09/01/2013 21:30, Andrea Giammarchi a écrit :
David ? You said: It could still make sense to wrap a DOM Node with a
proxy to perform [[Get]] and [[Set]], etc. but definitely not put it
in the DOM tree.
so this is the current scenario ... now, can you explain me a single
case where you
Le 09/01/2013 21:57, Andrea Giammarchi a écrit :
Last, but not least, even offline DOM proxies are pointless, here
another example without putting them in the DOM
What's an offline DOM Proxy?
var p = new Proxy(
document.createElement(p),
{}
);
try {
p.appendChild(
That's what you
Le 31/12/2012 07:19, Boris Zbarsky a écrit :
On 12/30/12 1:20 PM, Claude Pache wrote:
FWIW, I used the fact that, in IE 8 9, innerHTML is conveniently a
configurable accessor found at Element.prototype (in IE8) or
HTMLElement.prototype (in IE9), for correcting a quirk of its setter,
by
Le 30/12/2012 07:42, Boris Zbarsky a écrit :
On 12/29/12 11:08 AM, David Bruant wrote:
Boris, what initially triggered my questioning of the inherited accessor
setting is in this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html
OK, but that's a problem methods
Le 30/12/2012 17:48, Boris Zbarsky a écrit :
On 12/29/12 10:49 PM, Boris Zbarsky wrote:
One other note.
And one last note, promise.
In my opinion, we get too rarely this kind of feedback from implementors
on es-discuss. I'm personally learning a lot.
The point is that SpiderMonkey is
Hi,
It's been suggested a couple times on the list that the hope for
non-standard exotic objects (ES6 terminology for ES5 host objects) is to
make them at most as powerful as proxies.
The current definition of exotic object says:
Exotic objects may implement internal methods in any manner
Boris, what initially triggered my questioning of the inherited accessor
setting is in this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html
Mostly concerns about a mix of API securability and convenience. I
demonstrate that if every attribute is an inherited
Le 28/12/2012 09:23, Brendan Eich a écrit :
The trade-off is not between own data properties and shared
prototype-homed accessors.
Rather, it is between own and inherited accessors.
True. The reason is that WebIDL attributes have types that need to be
enforced [1] among other things.
In
Le 28/12/2012 10:29, Andreas Rossberg a écrit :
On 28 December 2012 05:38, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
No point whinging about it in appendices that either no one reads,
or else people read and think less of the spec on that account.
The fewer
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
standards? It would indicate that it's part of the standard, but is
a scar from history rather than a legit feature.
An intro would explain what this is all about
Le 28/12/2012 12:51, Andreas Rossberg a écrit :
On 28 December 2012 11:51, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to include __proto__ but not __defineGetter__ and friends.
__proto__ is in
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to include __proto__ but not __defineGetter__ and friends.
__proto__ is in
Le 27/12/2012 06:40, David Herman a écrit :
We've given up on the (non-existent) invariant that [[Prototype]] is
immutable. That doesn't mean we should set caution to the wind and
specify standard libraries that mutate [[Prototype]] links whenever it
happens to solve some problem.
As you'll
Le 27/12/2012 02:52, Brandon Benvie a écrit :
As an aside, ES itself can't self-host its own builtins in strict mode
because of the (two of the very few) semantic differences that exist
between strict mode and non-strict mode: non-strict thrower properties
(which I've come to consider an
Le 27/12/2012 06:32, Brendan Eich a écrit :
Mark S. Miller wrote:
Superstition aside, and once pre-ES5 browsers are not significant, the
only purpose of sloppy mode is for old code that must be kept running
without active maintenance.
That is a teleological statement -- you're talking about
Le 27/12/2012 20:04, Mark S. Miller a écrit :
This is a very good point. Is there any reason other than legacy
compat why WebIDL specifies inherited accessors rather than own
properties?
There is no legacy compat issue. Before WebIDL, the ECMAScript
representation of DOM objects was an absurd
Le 25/12/2012 23:01, Brandon Benvie a écrit :
I updated my Loader implementation to allow dynamically modifying the
options since it seems like a potentially good idea worth
investigating, and also seems like it might be indicated as the
desired functionality based on global and baseURL being
Le 26/12/2012 23:14, David Herman a écrit :
On Dec 24, 2012, at 2:34 PM, David Bruant bruan...@gmail.com wrote:
I've reading the loader API [1] and I was wondering if it was possible to
dynamically change the global. I think it is by doing the following, but tell
me if I'm wrong
Le 24/12/2012 10:48, Anne van Kesteren a écrit :
I thought I'd give a heads up as over on www-...@w3.org we're
discussing two cases where we likely need to change the prototype
chain of objects: document.open() and methods that do the equivalent
of document.adoptNode() (including that method
With the problem at hand and the solution currently being proposed
(nodes changing of [[Prototype]] on adoptNode), it will remain possible
to observe objects changing of [[Prototype]] after a delete
Object.prototype.__proto__. I don't know to what extends it's a good or
a bad thing, but I
Le 24/12/2012 15:50, Brandon Benvie a écrit :
That doesn't seem to be a problem. Host objects may be losing most/all
of their magic but it's certainly reasonable that they have privileged
access to capabilities. I think it makes sense to frame deleting
__proto__ as simply removing access to a
Hi,
I've reading the loader API [1] and I was wondering if it was possible
to dynamically change the global. I think it is by doing the following,
but tell me if I'm wrong:
const options = {
global : {
changeGlobal: function(g){
options.global = g;
.
David
On Mon, Dec 24, 2012 at 5:34 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
I've reading the loader API [1] and I was wondering if it was
possible to dynamically change the global. I think it is by doing
the following, but tell me if I'm wrong
a lot of code
to rewrite.
On Mon, Dec 24, 2012 at 5:34 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
I've reading the loader API [1] and I was wondering if it was
possible to dynamically change the global. I think it is by doing
the following
Le 21/12/2012 20:19, Tom Van Cutsem a écrit :
Given that there are plenty of cases where the configurable:true
contract is violated (i.e. non-deletable configurable properties),
and that it is still possible to fix the 3 violations of the
configurable:false contract, I think I'm swayed to
Le 19/12/2012 17:52, David Bruant a écrit :
(...)
3) WindowProxy objects reflect [Unforgeable] properties as own
configurable getters (properties like 'location' which are also
[PutForward] also have a setter)
A different solution is suggested [1] and has a lot of support. With
this solution
Le 20/12/2012 09:02, Tom Van Cutsem a écrit :
2012/12/19 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 19/12/2012 17:34, Brandon Benvie a écrit :
So the remaining situations in which it's difficult are in
the parent frame when you want to do this one
Le 20/12/2012 11:09, Tom Van Cutsem a écrit :
(...)
The right fix (at least, it feels like the obvious right fix to me),
is not to test whether O === Receiver, but rather just let the
algorithm explicitly test whether the Receiver object already defines
an own property with key P, to decide
Le 20/12/2012 13:18, Tom Van Cutsem a écrit :
2012/12/20 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 20/12/2012 09:02, Tom Van Cutsem a écrit :
I think I'm leaning towards non-configurable accessors with
deep-frozen (null-realm) getter/setter functions
Le 20/12/2012 18:51, Tom Van Cutsem a écrit :
2012/12/20 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 20/12/2012 13:18, Tom Van Cutsem a écrit :
Mark supports this view to enable reasoning about code of the form:
if ( ! Object.getOwnPropertyDescriptor(obj, foo
.
David
On Tue, Dec 18, 2012 at 9:31 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
Le 18/12/2012 18:08, Brendan Eich a écrit :
Mark S. Miller wrote:
That could work, but because of its complexity, I'm
leaning back towards
and {sealed:true, configurable:false} could mean even
inherited properties cannot be re-defined while sealed:false would be the
default?
Or maybe not ...
On Tue, Dec 18, 2012 at 9:31 AM, David Bruant bruan...@gmail.com wrote:
Hi,
Le 18/12/2012 18:08, Brendan Eich a écrit :
Mark S. Miller wrote:
That could
Le 19/12/2012 14:38, Tom Van Cutsem a écrit :
I too find the solution of non-configurable data properties
masquerading as configurable data properties bothersome. We have a
mechanism in place for describing the behavior of ES5 properties, yet
here is a case where we can't be honest about a
Le 19/12/2012 14:13, Claude Pache a écrit :
Hello,
In SpiderMonkey (and perhaps other JS engines?), there are conditional catch
clauses:
catch (exception if condition)
Could such a feature added to ECMAScript?
Rationale: Although try/catch mechanism was initially intended for
Le 19/12/2012 16:38, Claude Pache a écrit :
Le 19 déc. 2012 à 15:32, David Bruant bruan...@gmail.com a écrit :
Le 19/12/2012 14:13, Claude Pache a écrit :
Hello,
In SpiderMonkey (and perhaps other JS engines?), there are conditional catch
clauses:
catch (exception if condition
Le 19/12/2012 16:45, Brandon Benvie a écrit :
Another benefit is in not polluting the stack trace for actual errors,
which is actually a pretty big annoyance now for control flow
try...catch wrappers like for of shims.
This is making me realize that maybe the language needs a third way to
end
Le 19/12/2012 16:34, Brandon Benvie a écrit :
That's easily solved by making the accessor have a null prototype and
frozen though.
True, but it makes that you can't re-apply these getters and setters
with .call.
Since the getter doesn't inherit from Function.prototype any longer, you
have to
Hi,
In this message, I try to capture the conclusions of the couple of
recent threads that happened regarding WindowProxy and ES5 invariants
starting [1][2].
I understand the following conclusions:
1) WindowProxy don't allow scripts to set their internal [[Extensible]]
to false (attempts to
Le 19/12/2012 17:34, Brandon Benvie a écrit :
Also note that none of these properties are currently accessors so no
one has come to rely on being able to extract their getters. So
introducing them with neutered accessors would not have an impact on
existing code.
I fully agree. I wasn't
Le 18/12/2012 14:43, gaz Heyes a écrit :
On 14 December 2012 16:39, Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com wrote:
No, the whole point of Number.isNaN is to provide a definitively
test for NaN number values which cannot be tested for in the
usual way
Hi,
Le 18/12/2012 18:08, Brendan Eich a écrit :
Mark S. Miller wrote:
That could work, but because of its complexity, I'm leaning back
towards the configurable data property that refuses to be
configured approach. Is there a problem with that? It self-hosts fine.
Certainly this is the
Le 17/12/2012 13:51, Mark S. Miller a écrit :
On Mon, Dec 17, 2012 at 4:26 AM, Andreas Rossberg rossb...@google.com wrote:
On 17 December 2012 13:01, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 17, 2012 at 2:03 AM, Andreas Rossberg rossb...@google.com wrote:
I see the following
Le 17/12/2012 15:19, Anne van Kesteren a écrit :
If down the road we want to allow for the theoretical possibility of
having all platform APIs implemented in JavaScript, we might want a
sync Object.observe.
Which part of the platform needs a sync Object.observe?
I feel all platform APIs can be
Le 17/12/2012 15:56, Anne van Kesteren a écrit :
On Mon, Dec 17, 2012 at 3:39 PM, David Bruant bruan...@gmail.com wrote:
Which part of the platform needs a sync Object.observe?
(Thanks for the reply.)
Thanks for your post.
I think nothing does per se, but it might make
manner more
Hi Allen,
I don't think we're circling. I think we're doing a spiral (which may
give the impression that we're circling while we're moving forward).
More answers inline.
Le 15/12/2012 22:52, Allen Wirfs-Brock a écrit :
(...)
In ES5, we added reflection operations that allow ES code to
Hi,
ES5 invariants are silent when it comes to function identity of
non-configurable accessors. That is, for a given object o,
Object.getOwnPropertyDescriptor(o, 'a').get ===
Object.getOwnPropertyDescriptor(o, 'a').get
(two seperate calls) is not guaranteed.
The built-in
Le 15/12/2012 15:49, Sam Tobin-Hochstadt a écrit :
On Sat, Dec 15, 2012 at 9:27 AM, David Bruant bruan...@gmail.com wrote:
The way things are going, WindowProxy [Unforgeable] properties will be
non-configurable getters. If, upon underlying window change, the WindowProxy
is expected to keep
Hi,
On public-script-coord, Boris Zbarsky showed an example [1] where a
global variable is var-defined and then observed to be absent from the
global object it was attached to (because the WindowProxy has changed of
underlying window object).
The careful ECMAScript 5.1 reader knows that
Le 15/12/2012 18:23, Boris Zbarsky a écrit :
On 12/15/12 12:21 PM, David Bruant wrote:
On public-script-coord, Boris Zbarsky showed an example [1] where a
global variable is var-defined and then observed to be absent from the
global object it was attached to (because the WindowProxy has changed
Le 15/12/2012 18:37, Boris Zbarsky a écrit :
On 12/15/12 12:34 PM, David Bruant wrote:
No, nothing of the sort. The example shows it _present_ on the global
(the third alert in my example) but missing from the WindowProxy
(fourth alert).
I'm comparing the second and fourth alert (that's
401 - 500 of 1196 matches
Mail list logo
