Ok, thanks for your clarifying example.
I see your point. Basically you want obj[privateSymbol] to be a
high-integrity operation that proxies cannot even abort (unless they know
about the private symbol). That would give
private-symbol-keyed-property-access a special status, since other
important
On 16 January 2013 19:33, Brandon Benvie bran...@brandonbenvie.com wrote:
Without using modules as the indicator, how do you know whether code is
intended to be run as ES6 or not? Do let and const count as ES6
(retroactively applying to code using the old non-standard versions, which
are still
On 15 January 2013 17:16, Kevin Smith khs4...@gmail.com wrote:
It's really none of your business when you try to freeze my object whether
any of
(a) pre-existing private-symbol-named properties remain writable;
(b) weakmap-encoded private state remains writable;
(c) objects-as-closures
Hi,
I've been working on implementing Notification proxies as originally
proposed by Dean Tribble on this list [1] and then later expanded upon [2].
In a nutshell, their history is somewhat as follows:
1) original proxies could not emulate non-extensible objects or objects
with non-configurable
On 8 January 2013 22:33, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jan 8, 2013 at 1:30 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
so you are saying that Object.observe() does not suffer these problems ? Or
is just much simpler than Proxies ? ( yeah, I know, I guess both
Brendan Eich wrote:
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:
var wm = new WeakMap();
var o = {};
o[wm] = 12 // desugars to wm.set(o, 12)
var a =
First, I agree with David that security is important, both for
security per se and for modularity in general. ES5 improved the
language when it fixed the accidental leaks between the world of
objects and scope-chain objects, like thrown functions. ES5/strict
improved the language when it made
On 17 January 2013 18:00, Mark S. Miller erig...@google.com wrote:
I still have this position on classes. But I no longer buy that
pessimistic conclusion about WeakMaps. Consider how WeakMaps would be
used by the expansion of classes-with-private. Just 'cause it's on the
top of my head, below
On Thu, Jan 17, 2013 at 9:13 AM, Andreas Rossberg rossb...@google.com wrote:
Hm, I'm afraid I don't fully understand that example. There seems to
be a missing closing brace for the constructor, and I don't know what
the free occurrences of 'balance' are referring to. Also, the second
line of
Still not right. I screwed up the scoping of the balance variable.
Another correction coming soon.
On Thu, Jan 17, 2013 at 9:17 AM, Mark S. Miller erig...@google.com wrote:
On Thu, Jan 17, 2013 at 9:13 AM, Andreas Rossberg rossb...@google.com wrote:
Hm, I'm afraid I don't fully understand that
(As usual, trying to write code in a hurry actually cost more time :(.
Sorry to have spent every else's time as well :(. )
class Purse {
constructor(private balance) {}
getBalance() { return balance; }
makePurse() { return new Purse(0); }
deposit(amount, srcPurse) {
Mark S. Miller wrote:
I also agree with David that unique symbols are not an encapsulation
mechanism, but rather, merely a mechanism to avoid namespace
collisions.
However, after the Private Slots thread, I spent a sleepless night
chewing on getting rid of private symbols. I now think we
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
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 :
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
I just looked back at the example code in Distributed Electronic Rights in
JavaScript. It uses WeakMaps in two places: Fig1 line2 and Fig3 line2.
Both of these express objects using the objects-as-closures pattern, not
using classes. It's clearly affordable here since there are only 3 and 2
I believe it is impossible to do even a partially functional polyfill
for Maps and Sets in ES5.
Indeed, the only way to iterate through it is with the 'for (… of …)'
construct, which is sure to break in ES5.
I wish there was a way to polyfill it.
Something like 'Map.prototype.getKeys' could
There's multiple polyfills for Map, Set, and WeakMap (WeakMap not being
fully implementable, but close). Here's one:
http://benvie.github.com/harmony-collections.
On Thu, Jan 17, 2013 at 1:55 PM, Thaddee Tyl thaddee@gmail.com wrote:
I believe it is impossible to do even a partially
Dude, do you even read the spec?
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.5.4
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Thaddee Tyl [thaddee@gmail.com]
Sent: Thursday, January 17, 2013
On Thu, Jan 17, 2013 at 8:12 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Dude, do you even read the spec?
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.5.4
So this is just the wiki lacking some updates?
Andreas Rossberg wrote:
Actually, I don't see why this should have a measurable impact on
performance in practice. The generic case is dog-slow for JavaScript
anyway, what matters is how easy it is to specialise for the types
actually seen at runtime. And there, this would just add yet another
I have suggested before that it would be good to put control
over object iteration into the hands of the object authors, by
enabling them to override the slot iteration method.
I might be missing something, but isn't this basically covered
with the enumerable flag?
There are several object
It's really none of your business when you try to freeze my object
whether any of
(a) pre-existing private-symbol-named properties remain writable;
(b) weakmap-encoded private state remains writable;
(c) objects-as-closures environment variables remain writable.
Really. Not. Your (user).
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
The proxy target is important because it specifies some invariants
about the proxy (typeof, builtin brand, behavior of forwarding for
unspecified traps, values of internal properties like [[DateValue]],
[[NumberValue]], etc.).
That is probably the most important difference between direct
On 1/17/13 4:27 PM, Travis Leithead wrote:
This grabbed my attention :)
Oh, good. This is only my third try at getting a response... ;)
Is the idea to change the interface object such that instanceof can answer true
for any instance of that type (from any Javascript engine instance)? For
The Ephemeron gc technique
contributes nothing to the ability to reclaim space for such code
because of the relative lifetimes of the map and its keys.
Yes - my line-of-thought as well. If I may riff on your code a bit (ymmv):
class Purse {
// Move private field declaration
On Thu, Jan 17, 2013 at 1:13 PM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 19:30, Mark S. Miller a écrit :
2) Until ES7 provides private
I may have missed something. In the harmony proposal on the wiki [1] (is the
wiki down? I'm looking at google's cache),
I don't know, but seems
November's meeting had re-instituted computed property names to compensate
for the dropping @name support to allow for symbols to be used as method
names. AFAICT there's currently no actual way to create a private Symbol in
any active proposals for ES6, however (this was only covered as part of
On 1/17/13 4:48 PM, Travis Leithead wrote:
So x instanceof Element would be true if x is an Element, no matter what
its owner document is.
I don't think that's quite what you want. For multiple documents inside of a
single window instance this is already true:
Sure, but it's not true for
On Thu, Jan 17, 2013 at 1:50 PM, Mark S. Miller erig...@google.com wrote:
On Thu, Jan 17, 2013 at 1:13 PM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 19:30, Mark S. Miller a écrit :
2) Until ES7 provides private
I may have missed something. In the harmony proposal on the wiki [1]
On Thu, Jan 17, 2013 at 11:09 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
I think this sounds fine. Most web developers don't expect the current spec'd
behavior, even though to me it seems more natural.
While we have your attention:
It seems as if this approach to private class members also allows us to
describe private methods in a convenient way. Private methods can be
attached to the _prototype_ of the private field object, thus avoiding
per-instance allocation. Of course, the correct this value has to be
used in the
Is ... a new token that should be listed in Punctuator. I think it
should and it seems like a little miss for which I am happy to file a
bug, but I am not so sure as the proposal[1] doesn't include it.
It seems that Firefox implements it as a token. Test cases:
function x(. ..y) {}
function
This is implemented in esprima as a punctuator token as well:
https://github.com/ariya/esprima/blob/harmony/esprima.js#L724
On Thu, Jan 17, 2013 at 9:51 PM, Kang-Hao (Kenny) Lu kangh...@oupeng.comwrote:
Is ... a new token that should be listed in Punctuator. I think it
should and it seems
On Thu, Jan 17, 2013 at 9:40 PM, Kevin Smith 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 be
attached to the _prototype_ of the private field object, thus avoiding
If we’re making up new syntax, I think this would be much nicer if “private.x”
were spelled “this.@x” and “private(x)” were spelled “x.@”
Also, I don’t see why constructors need to use the “private.x” syntax whereas
other methods get to use the free variable?
With these in mind I give the
36 matches
Mail list logo
