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
Domenic Denicola wrote:
I still would like to see someone respond to jjb’s message though:
https://mail.mozilla.org/pipermail/es-discuss/2012-October/025531.html
JJB is right about same-origin allowing sharing so making postMessage
unnecessary, but same-origin does not mean a symbol created
On Oct 6, 2012, at 4:47 AM, David Bruant wrote:
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
On Oct 6, 2012, at 9:37 AM, Brendan Eich wrote:
Domenic Denicola wrote:
I still would like to see someone respond to jjb’s message though:
https://mail.mozilla.org/pipermail/es-discuss/2012-October/025531.html
JJB is right about same-origin allowing sharing so making postMessage
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
Allen Wirfs-Brock wrote:
On Oct 6, 2012, at 9:37 AM, Brendan Eich wrote:
Domenic Denicola wrote:
I still would like to see someone respond to jjb’s message though:
https://mail.mozilla.org/pipermail/es-discuss/2012-October/025531.html
JJB is right about same-origin allowing sharing so
David Bruant wrote:
Assuming every set of frame is a tree, maybe an HTML attribute could
define a script source which defines a module loader for how modules are
being imported in the iframe?
It's not all frames, even now. window.open can target existing windows
as well as create new ones
Allen Wirfs-Brock wrote:
Can the first approach be accomplished today using iframes?
Yes, using a named iframe (display:none) that everyone knows how to
find, you could hack this kind of SharedObjectDispensor up today.
Wouldn't be as pretty as we want, but doable so long as same-origin.
The issue, is providing access to an already created symbol across such
boundaries. As I have pointed out in other messages, this isn't a problem
that it unique to symbols. It is isomorphic with use cases for sharing any
kind of object across such boundaries.
I disagree. The only reason
On Oct 6, 2012, at 2:57 PM, Kevin Smith wrote:
The issue, is providing access to an already created symbol across such
boundaries. As I have pointed out in other messages, this isn't a problem
that it unique to symbols. It is isomorphic with use cases for sharing any
kind of object
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.
Ah yes.
Sounds good. As an aside, does the symbol in this
On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith khs4...@gmail.com wrote:
Sounds good. As an aside, does the symbol in this case provide any function
other than wrapping the string itself? Does the symbol carry any
information that the string does not, from the point of view of the script?
No,
On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith khs4...@gmail.com wrote:
Sounds good. As an aside, does the symbol in this case provide any function
other than wrapping the string itself? Does the symbol carry any
information
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Andreas Rossberg
Sent: Friday, October 5, 2012 14:46
On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith
2012/10/5 Domenic Denicola dome...@domenicdenicola.com
Indeed, which is why I'm not sure I understand what this idea is trying
to achieve. Is it more than just an ad hoc way to introduce a second
namespace?
Yes, is this noticeably better than just saying use
'__space_of_strings_string'?
On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg rossb...@google.comwrote:
On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith khs4...@gmail.com wrote:
Sounds good. As an aside, does the symbol in this case provide any
On Fri, Oct 5, 2012 at 9:51 AM, Dean Landolt d...@deanlandolt.com wrote:
On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg rossb...@google.comwrote:
On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith khs4...@gmail.com wrote:
Indeed, which is why I'm not sure I understand what this idea is
trying to achieve. Is it more than just an ad hoc way to introduce a
second namespace?
Presumably, so that such a namespace can be used with a
property-name-substitution syntax.
A question: is
var symbol = new
On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg rossb...@google.com wrote:
Indeed, which is why I'm not sure I understand what this idea is
trying to achieve. Is it more than just an ad hoc way to introduce a
second namespace?
I think what's going on as follows:
- Symbols, even when not
- Symbols, even when not used for encapsulated abstractions, are
great for avoiding the possibility of collision in the global string
namespace
- So, we (tc39) decided to use them for to replace the property name
currently called iterator in Spidermonkey.
- Currently, iterator works
On Fri, Oct 5, 2012 at 7:11 AM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:
Note also that `Symbol.for` has some really weird behavior. For
example, what does this evaluate to?
Symbol.for(x) instanceof Symbol
That depends if someone has previously evaluated `Symbol.for(x)` in
a
On Fri, Oct 5, 2012 at 11:23 AM, Mark S. Miller erig...@google.com wrote:
On Fri, Oct 5, 2012 at 7:11 AM, Sam Tobin-Hochstadt 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 Symbol
On Fri, Oct 5, 2012 at 7:11 AM, Sam Tobin-Hochstadt 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 Symbol
That depends if someone has previously evaluated `Symbol.for(x)` in
a
On Oct 5, 2012, at 7:11 AM, Sam Tobin-Hochstadt wrote:
On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg rossb...@google.com wrote:
Indeed, which is why I'm not sure I understand what this idea is
trying to achieve. Is it more than just an ad hoc way to introduce a
second namespace?
I
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
Tom Van Cutsem wrote:
2012/10/5 Domenic Denicola dome...@domenicdenicola.com
mailto:dome...@domenicdenicola.com
Indeed, which is why I'm not sure I understand what this idea is
trying to achieve. Is it more than just an ad hoc way to introduce
a second namespace?
Yes, is this
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
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!
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
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
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
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
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.
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.
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
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
One of the main use cases for symbols is for defining object protocols
that don't suffer from property name conflicts. The recently discussed
`iterator` and `toStringTag` method names fall into this category. The
idea is that we can implement the protocol by defining methods using
symbols, and
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 spite of this, but it is telling that we
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
Would it suffice to allow cross-frame sharing of symbols via postMessage and
its structured clone algorithm? They're immutable, right?
On Oct 3, 2012, at 15:01, Brendan Eich bren...@mozilla.org wrote:
Thanks for pointing this out. Python's dunder-prefixing or anything like it
in JS has that
A generic solution for cross-frame sharing would most elegant (instanceof...).
But how?
On Oct 3, 2012, at 21:01 , Brendan Eich bren...@mozilla.org wrote:
Thanks for pointing this out. Python's dunder-prefixing or anything like it
in JS has that advantage: you can spell the magic property
Not necessarily: you could have an environment that is global to all frames.
But that seems like a security risk.
On Oct 3, 2012, at 21:40 , Kevin Smith khs4...@gmail.com wrote:
So should there be a way in the language to create singleton symbols? If so,
how?
new
On Oct 3, 2012 12:39 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Would it suffice to allow cross-frame sharing of symbols via postMessage
and its structured clone algorithm? They're immutable, right?
I'm trying to follow this thread, but I'm having trouble understanding the
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 frame, and then have to use it carefully when
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
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 just
like typing dunder- ;-), or just 'iterator'
On Wed, Oct 3, 2012 at 5:09 PM, Brendan Eich bren...@mozilla.org wrote:
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
On Oct 3, 2012, at 2:09 PM, Brendan Eich wrote:
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
Dean Landolt wrote:
On Wed, Oct 3, 2012 at 5:09 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Domenic Denicola wrote:
Would it suffice to allow cross-frame sharing of symbols via
postMessage and its structured clone algorithm? They're
Allen Wirfs-Brock wrote:
Presumably a similar technique could be used for user defined symbols
that need to be shared across frame but the needs to be a way to
communicate the actual shared symbol values to the module instance
associated with each realm. In the above referenced message I
72 matches
Mail list logo
