2012/10/4 Brendan Eich bren...@mozilla.org
I don't think we've had a proposal yet for singleton modules per set of
connected realms. Possibly I missed it (something is tickling a memory but
I can't find a ref). It could be good!
This might have been the post that tickled your memory:
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
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, there is almost no point in having
a trap.
General
Tom Van Cutsem wrote:
2012/10/4 Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org
I don't think we've had a proposal yet for singleton modules per
set of connected realms. Possibly I missed it (something is
tickling a memory but I can't find a ref). It could be good!
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, there is
Kevin Smith wrote:
Dave Herman mentioned another idea: intern'ing strings as symbols.
You'd lose uniqueness but avoid colliding with any string. So
public @iterator = Symbol.intern('iterator');
Is this much better than just using 'iterator' or dunder-iterator?
Apologies,
As noted, this loses symbol uniqueness but avoids string vs. string name
collisions in objects. It takes on string-name collisions in the
intern'ed symbol table of course. That may be more manageable. Or not!
/be
Brendan Eich wrote:
Kevin Smith wrote:
Dave Herman mentioned another
presumably, looking up iterator in a registry of string/symbol key value
pairs. Creating a new entry if one isn't present, and regardless returning the
symbol value associated with the string.
public @iterator = Symbol('iterator');
conceptually could just as easily be expressed as:
public
Allen Wirfs-Brock wrote:
presumably, looking up iterator in a registry of string/symbol key
value pairs. Creating a new entry if one isn't present, and
regardless returning the symbol value associated with the string.
public @iterator = Symbol('iterator');
No, I wrote
On Oct 4, 2012, at 10:09 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
presumably, looking up iterator in a registry of string/symbol key value
pairs. Creating a new entry if one isn't present, and regardless returning
the symbol value associated with the string.
public @iterator =
On Thu, Oct 4, 2012 at 8:27 AM, Brendan Eich bren...@mozilla.com wrote:
Dave Herman mentioned another idea: intern'ing strings as symbols. You'd
lose uniqueness but avoid colliding with any string. So
public @iterator = Symbol.intern('iterator');
Is this much better than just using
On 10/3/2012 4:44 PM, Allen Wirfs-Brock wrote:
(oops, forgot to reply-all)
Begin forwarded message:
*From: *Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
*Date: *October 3, 2012 10:15:57 AM PDT
*To: *Herby Vojc(ík he...@mailbox.sk mailto:he...@mailbox.sk
*Subject:
Tab Atkins Jr. wrote:
It might be useful to expose this functionality with a more obvious
name, to underscore that you lose the secrecy/unforgability.
Symbol.public()?
We are mooting public as the keyword for non-private but unique symbols,
so that's ambiguous. ReallyPublic? :-P We want to
On Oct 4, 2012, at 11:29 AM, Brendan Eich wrote:
Tab Atkins Jr. wrote:
It might be useful to expose this functionality with a more obvious
name, to underscore that you lose the secrecy/unforgability.
Symbol.public()?
We are mooting public as the keyword for non-private but unique symbols,
On Thu, Oct 4, 2012 at 2:29 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
It might be useful to expose this functionality with a more obvious
name, to underscore that you lose the secrecy/unforgability.
Symbol.public()?
We are mooting public as the keyword for
Allen Wirfs-Brock wrote:
On Oct 4, 2012, at 11:29 AM, Brendan Eich wrote:
Tab Atkins Jr. wrote:
It might be useful to expose this functionality with a more obvious
name, to underscore that you lose the secrecy/unforgability.
Symbol.public()?
We are mooting public as the keyword for
Dean Landolt wrote:
On Thu, Oct 4, 2012 at 2:29 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
It might be useful to expose this functionality with a more
obvious
name, to underscore that you lose the
On Oct 4, 2012, at 11:50 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
Note that in most cases, you want to look up an already interned symbol name
rather than intern a new one. If the lookup falls back to creating, typos
will tend to get hidden.
I hope not! Otherwise the
On Thu, Oct 4, 2012 at 2:51 PM, Brendan Eich bren...@mozilla.com wrote:
Dean Landolt wrote:
On Thu, Oct 4, 2012 at 2:29 PM, Brendan Eich bren...@mozilla.commailto:
bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
It might be useful to expose this functionality with a more
Brendan wrote:
public @iterator = Symbol.intern('iterator');
Allen wrote:
public @iterator = Symbol('iterator');
[...]
public @iterator = RegistryOfWellKnownSymbols.lookup('iterator');
The big advantage of the last one is that RegistryOfWellKnownSymbols could
be virtualized, so that code
Dean Landolt wrote:
On Thu, Oct 4, 2012 at 2:51 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Urgh, namespace is misleading, it suggests Common Lisp's symbol
packages, the AS3/ES4 namespaces, XML namespaces. Here, @iterator
is not a prefix or part of a
On Thu, Oct 4, 2012 at 11:41 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Note that in most cases, you want to look up an already interned symbol
name rather than intern a new one.
One of the beautiful things about interning is that it is a pure function,
and so does not provide a
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
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]]
On Thu, Oct 4, 2012 at 12:55 PM, David Bruant bruan...@gmail.com wrote:
Le 04/10/2012
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
Presumably, this concern would also apply to associating programmer supplied
debug info with symbols
Mark S. Miller erig...@google.com wrote:
On Thu, Oct 4, 2012 at 11:41 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Note that in most cases, you want to look up an already interned
It depends what you mean by associating. What do you have in mind?
On Thu, Oct 4, 2012 at 1:18 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Presumably, this concern would also apply to associating programmer
supplied debug info with symbols
Mark S. Miller erig...@google.com wrote:
Not a mutable store. The interned symbols table is.
Can we get back to the somewhat pressing problem of @iterator vs.
'iterator' vs. Symbol.intern('iterator')? Firefox implements 'iterator'
currently, happy to change, no need to rush, but the trade-offs are
pretty clear.
Kevin Smith pointed
For a fresh symbol and an immutable association to a string fixed at
creation time, no problem.
For an interned symbol whose associated string name is the string interned
to get it, no problem.
On Thu, Oct 4, 2012 at 2:19 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
The private name
On Thu, Oct 4, 2012 at 3:24 PM, Brendan Eich bren...@mozilla.com wrote:
Dean Landolt wrote:
On Thu, Oct 4, 2012 at 2:51 PM, Brendan Eich bren...@mozilla.commailto:
bren...@mozilla.com wrote:
Urgh, namespace is misleading, it suggests Common Lisp's symbol
packages, the AS3/ES4
bugs.ecmascript.org appears to be down.
(100% packet loss when attempting to ping it.)
Any idea when it'll be back up?
-Michael
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
The private name proposal included the possibility of attaching a string value
to a symbol when it is created. The string could be used in debug output
(toString) for the symbol.
Mark S. Miller erig...@google.com wrote:
It depends what you mean by associating. What do you have in mind?
On
David Bruant wrote:
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
Dave had a suggestion for an alternative name to Symbol.intern, it's so
obvious in hindsight:
public @iterator = Symbol.from('iterator');
No jargon, perhaps at the price of connoting singleton symbol, but still.
/be
___
es-discuss mailing list
On Oct 4, 2012, at 4:02 PM, Brendan Eich wrote:
Dave had a suggestion for an alternative name to Symbol.intern, it's so
obvious in hindsight:
public @iterator = Symbol.from('iterator');
No jargon, perhaps at the price of connoting singleton symbol, but still.
Ticket filed: https://bugzilla.mozilla.org/show_bug.cgi?id=798138
Norbert
On Oct 4, 2012, at 15:18 , Michael Dyck wrote:
bugs.ecmascript.org appears to be down.
(100% packet loss when attempting to ping it.)
Any idea when it'll be back up?
-Michael
Up and running again.
Norbert
On Oct 4, 2012, at 16:21 , Norbert Lindenberg wrote:
Ticket filed: https://bugzilla.mozilla.org/show_bug.cgi?id=798138
Norbert
On Oct 4, 2012, at 15:18 , Michael Dyck wrote:
bugs.ecmascript.org appears to be down.
(100% packet loss when attempting to
Norbert Lindenberg wrote:
Up and running again.
Thanks!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock wrote:
On Oct 4, 2012, at 4:02 PM, Brendan Eich wrote:
Dave had a suggestion for an alternative name to Symbol.intern, it's so obvious
in hindsight:
public @iterator = Symbol.from('iterator');
No jargon, perhaps at the price of connoting singleton symbol, but still.
On 10/4/2012 11:30 AM, Allen Wirfs-Brock wrote:
On Oct 4, 2012, at 11:02 AM, Nicholas C. Zakas wrote:
On 10/3/2012 4:44 PM, Allen Wirfs-Brock wrote:
(oops, forgot to reply-all)
Begin forwarded message:
*From: *Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
*Date:
Nicholas C. Zakas wrote:
I agree, I'm not sure there is a rational default for Map, but I think
there is one for Set as an array (and it seems like most people agreed).
As with Set, I claim the default JSON for Map should be
[[key1, value1], ~~~ [keyN, valueN]]
with ~~~ as meta-ellipsis.
On Thu, Oct 4, 2012 at 8:07 PM, Nicholas C. Zakas
standa...@nczconsulting.com wrote:
On 10/4/2012 11:30 AM, Allen Wirfs-Brock wrote:
If there is such a thing as a rational default. And it gets harder to
define as you move from Set on to Map.
In either case, you are really defining a
On Thu, Oct 4, 2012 at 8:16 PM, Brendan Eich bren...@mozilla.org wrote:
Nicholas C. Zakas wrote:
I agree, I'm not sure there is a rational default for Map, but I think
there is one for Set as an array (and it seems like most people agreed).
As with Set, I claim the default JSON for Map
Rick Waldron wrote:
On Thu, Oct 4, 2012 at 8:16 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Nicholas C. Zakas wrote:
I agree, I'm not sure there is a rational default for Map, but
I think there is one for Set as an array (and it seems like
On Oct 4, 2012, at 5:32 PM, Rick Waldron wrote:
On Thu, Oct 4, 2012 at 8:16 PM, Brendan Eich bren...@mozilla.org wrote:
Nicholas C. Zakas wrote:
I agree, I'm not sure there is a rational default for Map, but I think there
is one for Set as an array (and it seems like most people
Kevin should weigh in, since he is thread-starter.
I'm blushing...
I'd like to back up a bit. Just to be clear, any two occurrences of:
Symbol.from(abcdefg); // or Symbol.for...
from any module, in any global context, will result in the same symbol?
Kevin
On Thu, Oct 4, 2012 at 8:36 PM, Kevin Smith khs4...@gmail.com wrote:
I'd like to back up a bit. Just to be clear, any two occurrences of:
Symbol.from(abcdefg); // or Symbol.for...
from any module, in any global context, will result in the same symbol?
Yes, that's the intent.
~TJ
On Thursday, October 4, 2012 at 9:29 PM, Allen Wirfs-Brock wrote:
On Oct 4, 2012, at 5:32 PM, Rick Waldron wrote:
On Thu, Oct 4, 2012 at 8:16 PM, Brendan Eich bren...@mozilla.org
(mailto:bren...@mozilla.org) wrote:
Nicholas C. Zakas wrote:
I agree, I'm not sure there is a
Yes, that's the intent.
And the strings supplied to Symbol.for/from form a single namespace across
the entire executing environment?
So if an author wanted to guarantee no conflicts, they would need to use a
suitable globally unique string (like a uuid or reverse DNS name, or
something else
Kevin Smith wrote:
Yes, that's the intent.
And the strings supplied to Symbol.for/from form a single namespace
across the entire executing environment?
Across the observably connected realms. Independent window/frame graphs
that are disconnected, no need or way to tell.
So if an
On Oct 4, 2012, at 9:02 PM, Rick Waldron wrote:
On Thursday, October 4, 2012 at 9:29 PM, Allen Wirfs-Brock wrote:
On Oct 4, 2012, at 5:32 PM, Rick Waldron wrote:
On Thu, Oct 4, 2012 at 8:16 PM, Brendan Eich bren...@mozilla.org wrote:
Nicholas C. Zakas wrote:
I agree, I'm not
53 matches
Mail list logo
