What's the use case for Symbol.keyFor?
On Thu, Sep 26, 2013 at 11:31 PM, Mark S. Miller erig...@google.com wrote:
Some other invariants:
For all strings S, Symbol.for(S) === Symbol.for(S)
For all Symbols R made by Symbol.for(S) for some string S
Symbol.keyFor(R) === Symbol.keyFor(R) // I
On Sep 27, 2013, at 5:24 AM, Mark S. Miller wrote:
That's fine for an unregistered Symbol, i.e., one created by calling the
Symbol constructor. What about a registered Symbol, i.e., one created by
calling Symbol.for?
Perhaps, there could be a second optional parameter,
On Sep 27, 2013, at 7:52 AM, Erik Arvidsson wrote:
What's the use case for Symbol.keyFor?
The use case was actually suggested in a response to dherman earlier in this
thread when he mentioned sharing symbols between workers.
If you need to serialize an object with symbol keyed properties
On Fri, Sep 27, 2013 at 11:28 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
The use case was actually suggested in a response to dherman earlier in this
thread when he mentioned sharing symbols between workers.
We don't need to expose that to user-script though. That would be part
of the
David Herman wrote:
We've seen this movie before: arrays are just objects, integers are just
doubles, environment records are just objects...
Some of my biggest regrets! Top five list material (don't list the other
two, please).
/be
___
The structured cloning algorithm is the last thing I want to use to
communicate between workers. I advise avoiding it like the plague, instead
serializing to JSON, sending the string, and unserializing on the other
side. This also keeps the semantics of inter-worker communication aligned
with the
So a more polite answer is: communicating registered symbols between
machines, with the same semantics as communicating them over a bit channel
within the same address space. I can't use structured clone between
machines.
On Fri, Sep 27, 2013 at 8:53 AM, Mark S. Miller erig...@google.com wrote:
On Fri, Sep 27, 2013 at 11:53 AM, Mark S. Miller erig...@google.com wrote:
The structured cloning algorithm is the last thing I want to use to
communicate between workers. I advise avoiding it like the plague, instead
serializing to JSON, sending the string, and unserializing on the other
Yeah, those also don't work between machines. So at least we have a clean
conceptual split between use cases. My points apply to the case that wants
to work uniformly with the inter-machine case.
On Fri, Sep 27, 2013 at 8:57 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Sep 27, 2013 at
Le 27/09/2013 17:57, Anne van Kesteren a écrit :
On Fri, Sep 27, 2013 at 11:53 AM, Mark S. Miller erig...@google.com wrote:
The structured cloning algorithm is the last thing I want to use to
communicate between workers. I advise avoiding it like the plague, instead
serializing to JSON, sending
On Fri, Sep 27, 2013 at 11:54 AM, Mark S. Miller erig...@google.com wrote:
So a more polite answer is: communicating registered symbols between
machines, with the same semantics as communicating them over a bit channel
within the same address space. I can't use structured clone between
On Fri, Sep 27, 2013 at 12:07 PM, David Bruant bruan...@gmail.com wrote:
I can't speak for Mark, but I feel his advice is missing details. For
instance, transferables are missing (covers ArrayBuffer and rendering
contexts, though, I'd prefer parallel iframes to passing rendering contexts
On Sep 27, 2013, at 9:07 AM, David Bruant bruan...@gmail.com wrote:
I agree with the intent of keeping semantics of inter-worker and
inter-machine very close, but the difference in terms makes very clear that
not being able to differenciate the 2 cases incurs an information loss that
can
On Sep 27, 2013, at 8:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Sep 27, 2013, at 7:52 AM, Erik Arvidsson wrote:
What's the use case for Symbol.keyFor?
The use case was actually suggested in a response to dherman earlier in this
thread when he mentioned sharing symbols
On Sep 27, 2013, at 10:02 AM, David Herman dher...@mozilla.com wrote:
- don't share symbols between workers
Follow-up thought: it seems there are actually two concepts that both get
grouped under realms and yet might warrant distinction. These correspond on
the web to two same-origin windows
On Sep 27, 2013, at 10:14 AM, David Herman dher...@mozilla.com wrote:
On Sep 27, 2013, at 10:02 AM, David Herman dher...@mozilla.com wrote:
- don't share symbols between workers
Follow-up thought: it seems there are actually two concepts that both get
grouped under realms and yet might
On Sep 27, 2013, at 12:05 PM, David Herman dher...@mozilla.com wrote:
export const serialize = m ? m.serialize : new Symbol(friendly name);
And... of course I meant `Symbol()` rather than `new Symbol()`. Haven't
retrained my muscle memory from the days of the object-based API. ;)
Dave
Whether you personally use it, for-in is a reality. Introspection of
objects happens, so if you ship a library that's putting meta-level
properties into objects it needs to make them non-enumerable to be robust
in the face of client code that uses for-in but isn't prepared to
understand the
/ Whether you personally use it, for-in is a reality. Introspection of
// objects happens, so if you ship a library that's putting meta-level
// properties into objects it needs to make them non-enumerable to be robust
// in the face of client code that uses for-in but isn't prepared to
//
In this case I doubt @iterator or @toStringTag should be visible. (And I
know there a better ways to test for empty objects, but for-in testing is
common enough...)
Thanks Andre! I fear this example merely begs the question of whether such
an object should be considered empty with respect
We've found the need for serializable functions in AmbientTalk, which,
like JS, encourages a style of programming that makes significant use
of lexical nesting. We have found that this programming style makes
that requiring serializable functions to be closed is indeed too
On Fri, Sep 27, 2013 at 12:37 PM, Kevin Smith zenpars...@gmail.com wrote:
Whether you personally use it, for-in is a reality. Introspection of
objects happens, so if you ship a library that's putting meta-level
properties into objects it needs to make them non-enumerable to be robust
in the
On Thu, Sep 26, 2013 at 10:01 PM, Kevin Smith zenpars...@gmail.com wrote:
- If you are going to use a symbol registry, then you really need to prove
how that is any better than just using the registry key itself.
During the meeting I tried to make the point that symbols would be
better for
Kevin Smith wrote:
Whether you personally use it, for-in is a reality. Introspection
of objects happens, so if you ship a library that's putting
meta-level properties into objects it needs to make them
non-enumerable to be robust in the face of client code that uses
for-in
On 9/27/2013 9:58 PM, Kevin Smith wrote:
In this case I doubt @iterator or @toStringTag should be visible.
(And I know there a better ways to test for empty objects, but
for-in testing is common enough...)
Thanks Andre! I fear this example merely begs the question of whether
such
Tom Van Cutsem wrote:
var f = function(x,y) (z) {
Tiny bike-shed-ish comment that we need a linking punctuator so that
arrow function syntax can be extended likewise:
var f = function (x, y) : (z) {...}
Arrow form showing expression body:
var f = (x, y) : (z) = x*y/z;
An alternative
Tiny bike-shed-ish comment that we need a linking punctuator so that
arrow function syntax can be extended likewise:
var f = function (x, y) : (z) {...}
Arrow form showing expression body:
var f = (x, y) : (z) = x*y/z;
FWIW, I like the semi colon. However, I prefer
|
Maybe, but:
(1) annotations are user-hostile even in a language like Rust, wherefore
type-and-lifetime inference, which you are not proposing.
(2) we need a sane default, if not inference.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
This is Rev 19, The Sept. 27 Draft
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#september_27_2013_draft_rev_19
And the HTML is available at
http://people.mozilla.org/~jorendorff/es6-draft.html
Changes include:
Better internal cross-linking
Restored NoIn expression
On 09/26/2013 04:22 PM, Yehuda Katz wrote:
On Thu, Sep 26, 2013 at 4:20 PM, Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com wrote:
On Sep 26, 2013, at 4:12 PM, Brandon Benvie wrote:
On 9/26/2013 4:09 PM, Allen Wirfs-Brock wrote:
The newness was using
Waldemar Horwat mailto:walde...@google.com
September 27, 2013 3:45 PM
It's even back in ES6 with then. I find it truly weird that we're
trying to use two different mechanisms to get the then and iterate
metaproperties. We should be cutting down the complexity, not adding
to it in a manner
All the noise we made about Object.extend was unclear? From jQuery:
https://github.com/jquery/**jquery/blob/master/src/core.**js#L157https://github.com/jquery/jquery/blob/master/src/core.js#L157
Many similar functions, going back to Prototype's Object.extend:
Object.extend =
div id=@iterator/div
scriptalert(document.getElementsByTagName(div)[@iterator])/script
This is a good point, and one which I was trying to reason about (way)
upthread. This might do it - have to sleep on it, though...
{ Kevin }
___
es-discuss
33 matches
Mail list logo
