One think I have suggested back in a time may has an interesting property to a private symbol sharing. What if private symbols were of "function" type instead of "object", where given a symbol 'foo'foo(object, arg1, arg2, …)desugars toobject[foo](arg1, arg2, …)That would make symbol sharing as legi
\o/
/be
Brandon Benvie wrote:
On 8/2/2013 1:31 PM, Erik Arvidsson wrote:
You can already use string literals as property names:
```js
class C {
"sys/iterator"() {}
}
```
Oh right, method syntax threw me off, but this is completely valid.
___
es
On 8/2/2013 1:31 PM, Erik Arvidsson wrote:
You can already use string literals as property names:
```js
class C {
"sys/iterator"() {}
}
```
Oh right, method syntax threw me off, but this is completely valid.
___
es-discuss mailing list
es-discuss@
You can already use string literals as property names:
```js
class C {
"sys/iterator"() {}
}
```
On Fri, Aug 2, 2013 at 4:28 PM, Brandon Benvie wrote:
> On 8/2/2013 1:21 PM, Tab Atkins Jr. wrote:
>>
>> On Fri, Aug 2, 2013 at 12:45 PM, Kevin Smith wrote:
>>>
>>> class C {
>>> "sy
On 8/2/2013 1:21 PM, Tab Atkins Jr. wrote:
On Fri, Aug 2, 2013 at 12:45 PM, Kevin Smith wrote:
class C {
"sys/iterator"() { }
"foo/userDefined"() { }
}
How do you distinguish these from plain strings? Or are you not
distinguishing them, and just assuming that we ad
On Fri, Aug 2, 2013 at 12:45 PM, Kevin Smith wrote:
> class C {
> "sys/iterator"() { }
> "foo/userDefined"() { }
> }
How do you distinguish these from plain strings? Or are you not
distinguishing them, and just assuming that we add a way to use string
literals as method n
I like this. Cc'ing Dave and Sam to get to top of their queues.
/be
Kevin Smith wrote:
- Anarchy is not appropriate when the number of names which must be
*simultaneously distinguishable* passes some threshold. The longer
the names, the higher that threshold will be. In this case, the set
o
>
> I still see big usability problems with UUIDs, even if used to name
> non-enumerable properties. Tools help but the core language provides no
> sugar, salt, or paprika. Just a very sour/bitter hex-string...
>
>
I agree.
There are only three different approaches to collision avoidance that I'm
On Wed, Jul 31, 2013 at 7:11 PM, Brendan Eich wrote:
>> On Wed, Jul 31, 2013 at 5:34 PM, Brendan Eich wrote:
>>>
>>> You say either and I say either,
>>> You say neither and I say neither
>>> Either, either neither, neither
>>> Let's call the whole thing off.
>>>
>>> You like potato and I like po
Tab Atkins Jr. wrote:
On Wed, Jul 31, 2013 at 5:34 PM, Brendan Eich wrote:
You say either and I say either,
You say neither and I say neither
Either, either neither, neither
Let's call the whole thing off.
You like potato and I like potahto
You like tomato and I like tomahto
Potato, potahto, t
On Wed, Jul 31, 2013 at 5:34 PM, Brendan Eich wrote:
> You say either and I say either,
> You say neither and I say neither
> Either, either neither, neither
> Let's call the whole thing off.
>
> You like potato and I like potahto
> You like tomato and I like tomahto
> Potato, potahto, tomato, tom
You say either and I say either,
You say neither and I say neither
Either, either neither, neither
Let's call the whole thing off.
You like potato and I like potahto
You like tomato and I like tomahto
Potato, potahto, tomato, tomahto.
Let's call the whole thing off
- Ira Gershwin
I feel l
On Wed, Jul 31, 2013 at 11:34 AM, Dean Landolt wrote:
> On Wed, Jul 31, 2013 at 1:57 PM, Tab Atkins Jr.
> wrote:
>> On Wed, Jul 31, 2013 at 10:56 AM, Brendan Eich
>> wrote:
>> > Domenic Denicola wrote:
>> >> org.ecmascript.es6.builtins.iterator?
>> >
>> > You forgot the smiley, or: nooo!
Why a third namespace when there's the built-in modules that functions
nicely as our registry?
On Wed, Jul 31, 2013 at 1:57 PM, Tab Atkins Jr. wrote:
> On Wed, Jul 31, 2013 at 10:56 AM, Brendan Eich
> wrote:
> > Domenic Denicola wrote:
> >> org.ecmascript.es6.builtins.iterator?
> >
> > You forg
> unique string (uuid or otherwise) suffer same problem if generated in 2
> different realm unaware of each other.
>
I meant hard-coding such a well-known unique string into both versions of
the library. That solves the problem.
{ Kevin }
___
es-discus
On Wed, Jul 31, 2013 at 10:56 AM, Brendan Eich wrote:
> Domenic Denicola wrote:
>> org.ecmascript.es6.builtins.iterator?
>
> You forgot the smiley, or: nooo!!
Which is why I (not in jest) suggested the third property namespace,
for language-defined symbols. ^_^
~TJ
__
You forgot the smiley, or: nooo!!
/be
Domenic Denicola wrote:
org.ecmascript.es6.builtins.iterator?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Jul 31, 2013 at 1:50 PM, Kevin Smith wrote:
>
> unique string (uuid or otherwise) suffer same problem if generated in 2
>> different realm unaware of each other.
>>
>
> I meant hard-coding such a well-known unique string into both versions of
> the library. That solves the problem.
>
A
org.ecmascript.es6.builtins.iterator?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
for what is worth it, this worked quite well in a single realm with no
enumerability though:
https://gist.github.com/WebReflection/5238782#file-gistfile1-js-L1
// example
var sym = new Symbol;
var o = {};
o[sym] = 123;
console.log(o[sym]);
On Wed, Jul 31, 2013 at 10:49 AM, Brendan Eich wrote:
Andrea Giammarchi wrote:
unique string (uuid or otherwise) suffer same problem if generated in
2 different realm unaware of each other.
Mark's point about UUIDs generated by robust RBGs (Random Bit
Generators) addresses the collision risk: it is astronomically small.
In any case, as mentione
On Wed, Jul 31, 2013 at 12:27 PM, Mark Miller wrote:
> On Wed, Jul 31, 2013 at 8:36 AM, Erik Arvidsson
> wrote:
>
>> One way could be to have a shared module with the symbol that both
>> w1.1 and w1.2 uses.
>>
>> // w-symbols.js
>> export let foo = Symbol();
>>
>> // w-1.1.js
>> import {foo} fro
Seems like we are yet again talking ourselves out of unique symbols --
or symbols in general?
I still see big usability problems with UUIDs, even if used to name
non-enumerable properties. Tools help but the core language provides no
sugar, salt, or paprika. Just a very sour/bitter hex-string.
unique string (uuid or otherwise) suffer same problem if generated in 2
different realm unaware of each other.
In any case, as mentioned before, this is very similar to instanceof or
isPrototypeOf/getPrototypeOf and I don't see many concrete real cases
problems except being able to serialize and d
>
>
> To avoid accidental collision on the interned symbols, you must avoid
> accidental collision on the strings used as keys in this registration
> table. This demands exactly as much collision resistant of string choices
> as using the strings directly. And therefore also demands strings which a
On Wed, Jul 31, 2013 at 9:27 AM, Mark Miller wrote:
> To avoid accidental collision on the interned symbols, you must avoid
> accidental collision on the strings used as keys in this registration table.
> This demands exactly as much collision resistant of string choices as using
> the strings dir
On Wed, Jul 31, 2013 at 8:36 AM, Erik Arvidsson wrote:
> One way could be to have a shared module with the symbol that both
> w1.1 and w1.2 uses.
>
> // w-symbols.js
> export let foo = Symbol();
>
> // w-1.1.js
> import {foo} from 'w-symbols';
> ...
>
> // w-1.2.js
> import {foo} from 'w-symbols';
One way could be to have a shared module with the symbol that both
w1.1 and w1.2 uses.
// w-symbols.js
export let foo = Symbol();
// w-1.1.js
import {foo} from 'w-symbols';
...
// w-1.2.js
import {foo} from 'w-symbols';
...
Other options include storing the symbol in some kind of global
registr
We have exactly the same problem with inter-realm instanceof.
The module system is the obvious solution for system-defined unique
symbols. I've been assuming it could be hacked (one way or another) into
giving us a registry where we could map string keys to symbols across
realms. I get that this h
This point is important enough that I'm resending as the start of a new
thread.
On Wed, Jul 31, 2013 at 7:50 AM, Mark S. Miller wrote:
>
> In thinking about this, I become ever more puzzled about the versioning
> and inter-realm problems for user-defined unique symbols -- I think it may
> be a
30 matches
Mail list logo
