I'm in the process of matching up an ES6 module loader with AMD support to
the RequireJS tests, and have a question on concatenated module files.
If I have a module, foo.js, which defines its own name and its dependencies:
foo.js:
module 'foo' {
export var p = 'value';
}
module
2013/7/31 Allen Wirfs-Brock al...@wirfs-brock.com
We could define a new predicate Array.isArrayLike with a proxy friendly
extensions mechanism (@@isArrayLike). It wouldn't be the same test as
Array.isArray and the result would be more a statement of intent than an
absolute guarantee.
Just as a heads up, in a thread titled Overlap between StreamReader
and FileReader on public-webapps an API for IO streams is being
iterated over:
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/thread.html#msg0
Your input would be appreciated!
--
http://annevankesteren.nl/
I think one of us is confused here. How are you importing from
'foo.js'? If you're importing from it, expecting that it's the body of
a module, then you'll get a syntax error -- modules don't nest.
You could configure the loader so that it treats 'foo.js' as
containing the definition of the 'foo'
On Jul 31, 2013 1:39 AM, Mark S. Miller erig...@google.com wrote:
Only useful for instance-private instance variables, in which case you
may as well use lexically captured per-instance state.
Also useful for methods where different subclasses needs to specialize the
behavior.
We've tripped on
Aside from this confinement issue, all other the advantages that unique
symbols have over unique-ish strings seem minor to me. The biggest is
default non-enumerability, when we're getting away (admittedly slowly) from
enumerability being significant anyway. IMO, if the only advantages of
On Jul 31, 2013 6:40 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
On the flip side: DOM nodelists, while behaviorally similar to arrays,
also don't pass the Array.isArray test. Does this anger developers? Or is
this common wisdom and people have learned to live with the differences
between
On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith zenpars...@gmail.com wrote:
Aside from this confinement issue, all other the advantages that unique
symbols have over unique-ish strings seem minor to me. The biggest is
default non-enumerability, when we're getting away (admittedly slowly) from
I want to refer to the algorithm JSON.parse defines, but not
necessarily JSON.parse itself (as that can be overridden). Is there
any preferred way to do that? Or otherwise can JSONParse hook be
introduced?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22840
On Tue, Jul 30, 2013 at 7:15 PM, Brandon Benvie bben...@mozilla.com wrote:
I fully admit that this may be overkill to support an edge case, and as I
said I don't even know if it's expected for multi-realm usage to happen.
Nodes moving between documents (with their own globals) is certainly
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 erig...@google.com wrote:
In thinking about this, I become ever more puzzled about the versioning
and inter-realm problems for user-defined unique symbols -- I
On Wed, Jul 31, 2013 at 10:38 AM, Mark S. Miller erig...@google.com wrote:
Only useful for instance-private instance variables, in which case you
may as well use lexically captured per-instance state.
Also useful for methods where different subclasses needs to specialize the
behavior.
Mark S. Miller wrote:
Only useful for instance-private instance variables, in which
case you may as well use lexically captured per-instance state.
No, friend is shared between two classes, no way to make a
closure per instance extending over both constructors. Pretend
Mark S. Miller wrote:
Don't ever use MAC addresses, dates, times, positions, etc, as sources
of uniqueness.
uuidgen implementations have used MAC addresses in the past, which I
believe led to a public collision.
What a collision resistant string? Use 128 bits of entropy. You'll get
an
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
Erik Arvidsson wrote:
On Wed, Jul 31, 2013 at 10:38 AM, Mark S. Millererig...@google.com wrote:
Only useful for instance-private instance variables, in which case you
may as well use lexically captured per-instance state.
Also useful for methods where different subclasses needs to specialize
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
On 7/31/13 at 8:35 AM, bren...@mozilla.com (Brendan Eich) wrote:
uuidgen implementations have used MAC addresses in the past, which I believe
led to a public collision.
In 1998 we (Electric Communities) discovered that people using
AOL software to access the internet were all assigned the
On Wed, Jul 31, 2013 at 10:50 AM, Mark S. Miller erig...@google.com wrote:
On Wed, Jul 31, 2013 at 6:24 AM, Dean Landolt d...@deanlandolt.comwrote:
On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith zenpars...@gmail.comwrote:
Aside from this confinement issue, all other the advantages that
On Wed, Jul 31, 2013 at 8:36 AM, Erik Arvidsson erik.arvids...@gmail.comwrote:
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
I think the spec says that
Math.hypot() === NaN
Math.hypot(1) === NaN
Math.hypot(1, 2, 2, 4) === 3
Math.hypot(3, 4, undefined) === NaN
Is that correct?
I'm basing this on paragraph 4 of clause 15, plus the first sentence
of 15.8.2, plus the fact that Math.hypot() appears to
On Wed, Jul 31, 2013 at 9:27 AM, Mark Miller erig...@gmail.com 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
Mark S. Miller wrote:
On Wed, Jul 31, 2013 at 8:35 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Mark S. Miller wrote:
Don't ever use MAC addresses, dates, times, positions, etc, as
sources of uniqueness.
uuidgen implementations have used MAC
Brendan Eich wrote:
Gathering entropy enough to make a UUID is work. A crypto module's
RBG should be up to it. Browsers have those, but we haven't yet
required any such thing in ECMA-262, and I expect some
implementations will be crypto-module-free and cheese out on the
On Wed, Jul 31, 2013 at 6:21 PM, Dean Landolt d...@deanlandolt.com wrote:
That leaves default non-enumerability. Consider the fact that object
literal methods are enumerable. Why should choosing a unique name as
opposed to an identifier for a method have any bearing on enumerability?
I
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 are
Heya! I, Mark, and others have been hashing out our remaining
differences on Promises privately, and are all happy with each other
now, with only two remaining issues to be decided in a larger
audience. Anne says that we should be able to get DOM Promises on
track with this consensus if we
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
Just some terminology questions for this new proposal...
From: Tab Atkins Jr. [jackalm...@gmail.com]
whatever p resolves to, gets passed to the flatMap() callbacks.
What does resolves mean in this context? I don't believe you are using it in
the same way that it is used in Promises/A+ or DOM
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
On Wed, Jul 31, 2013 at 12:27 PM, Mark Miller erig...@gmail.com wrote:
On Wed, Jul 31, 2013 at 8:36 AM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
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();
//
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
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
Ok sure, while I understand nesting is no longer supported, it could
potentially still make sense in terms of defining the module being an
operation.
Consider as an equivalent to the example the following:
foo.js:
System.set('foo', new Module({
p: 'value'
}));
System.set('foo/dependency', new
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 zenpars...@gmail.com 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
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
Agreed -- I was mostly joking. But there's a reason the proposal called
for a string prefix -- they will be reflected in the raw. Unlike Math.PI,
this raw value is meaningless.
Yes - a minor issue with unique strings is that you will see distractingly
ugly property names in your debugger.
On Wed, Jul 31, 2013 at 10:56 AM, Brendan Eich bren...@mozilla.com 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
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-discuss
Actually, if module statements are not allowed at all within imported
modules, this invalidates the example, which is the most important use case
for module statements.
Basically it would be impossible to load the module declarations for a
modules dependencies in the same request as an import
[Gah, resending because I'm being *way* too loose with my terminology.
Ignore previous email - this one has identical content, but uses
terms correctly.] (Scratch that, I added a new point #3 at the end of
the email.)
[For the purposes of this email, a promise accepting or rejecting
means that
From: Tab Atkins Jr. [jackalm...@gmail.com]
For the purposes of this email, a promise accepting or rejecting means
that its resolver's accept() or reject() method was called, or the equivalent
internal magic. fulfill means accept or reject. resolve means adopt
or accept, depending on
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. jackalm...@gmail.comwrote:
On Wed, Jul 31, 2013 at 10:56 AM, Brendan Eich bren...@mozilla.com
wrote:
Domenic Denicola wrote:
On Wed, Jul 31, 2013 at 11:38 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Tab Atkins Jr. [jackalm...@gmail.com]
For the purposes of this email, a promise accepting or rejecting means
that its resolver's accept() or reject() method was called, or the
equivalent internal
On Wed, Jul 31, 2013 at 11:34 AM, Dean Landolt d...@deanlandolt.com wrote:
On Wed, Jul 31, 2013 at 1:57 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Wed, Jul 31, 2013 at 10:56 AM, Brendan Eich bren...@mozilla.com
wrote:
Domenic Denicola wrote:
org.ecmascript.es6.builtins.iterator?
Does this all mean that you're ok with having promises-for-promises?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Jul 31, 2013 at 12:48 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Does this all mean that you're ok with having promises-for-promises?
I've always been okay with that. ^_^ This consensus details how to
handle nested promises (use .flatMap()) *and* how to ignore that and
just
From: Mark S. Miller [erig...@google.com]
One thing I think Domenic is missing that I also missed at first: Once we
introduce .flatMap, then we need a distinct accepted state that is neither
fulfilled nor rejected. The issue is that p.then does not fire until the
promise p is fulfilled or
Le 31 juil. 2013 à 20:23, Tab Atkins Jr. jackalm...@gmail.com a écrit :
The first issue still up for community discussion involves the
definition of promise-like.
We'd like the definition to be: (a) a Promise or subtype, or (b) a
branded non-Promise (with the branding done via Symbol or
On Wed, Jul 31, 2013 at 3:52 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Mark S. Miller [erig...@google.com]
One thing I think Domenic is missing that I also missed at first: Once
we introduce .flatMap, then we need a distinct accepted state that is
neither fulfilled nor
On Wed, Jul 31, 2013 at 3:53 PM, Claude Pache claude.pa...@gmail.com wrote:
Le 31 juil. 2013 à 20:23, Tab Atkins Jr. jackalm...@gmail.com a écrit :
The first issue still up for community discussion involves the
definition of promise-like.
We'd like the definition to be: (a) a Promise or
From: Mark Miller [erig...@gmail.com]
On Wed, Jul 31, 2013 at 3:52 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Mark S. Miller [erig...@google.com]
One thing I think Domenic is missing that I also missed at first: Once we
introduce .flatMap, then we need a distinct accepted
Taking a tip from Mark and pulling my own words out of the Agreeing on
user-defined symbols thread:
This serialize point is good, and gets to something I raised with Allen
yesterday, which he originally stated: realms should be *more* isolated.
We may want distribuited (cross-machine) realms.
Mark S. Miller wrote:
On Wed, Jul 31, 2013 at 5:00 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Taking a tip from Mark and pulling my own words out of the
Agreeing on user-defined symbols thread:
This serialize point is good, and gets to something I
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
On Wed, Jul 31, 2013 at 5:34 PM, Brendan Eich bren...@mozilla.com 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,
On Wed, Jul 31, 2013 at 5:26 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
On Wed, Jul 31, 2013 at 5:00 PM, Brendan Eich bren...@mozilla.commailto:
bren...@mozilla.com wrote:
Taking a tip from Mark and pulling my own words out of the
Agreeing on user-defined
Mark S. Miller wrote:
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html
So regarding this issue, what does it say?
You want me to read and interpret and digest it for ya? :-P
Changing document.domain changes effective script origin, which affects
some but not
Tab Atkins Jr. wrote:
On Wed, Jul 31, 2013 at 5:34 PM, Brendan Eichbren...@mozilla.com 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
On Wed, Jul 31, 2013 at 6:44 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
http://www.whatwg.org/specs/**web-apps/current-work/**
multipage/origin-0.htmlhttp://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html
So regarding this issue, what does it
Mark S. Miller wrote:
That's not the hard problem relevant to the current question. Given
two frames both starting at foo.bar.com http://foo.bar.com. While
they're both there, their object graphs become arbitrarily entangled,
which is as it should be. Then, one of them truncates to bar.com
But does the html5 spec say anything about what is supposed to happen?
On Wed, Jul 31, 2013 at 7:29 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
That's not the hard problem relevant to the current question. Given two
frames both starting at foo.bar.com
Mark S. Miller wrote:
But does the html5 spec say anything about what is supposed to happen?
Sure:
3.1.2Security
*Ready for first implementations*
User agents must throw a|SecurityError
http://www.whatwg.org/specs/web-apps/current-work/#securityerror|exception
whenever any
I don't care about the document objects. What about access between regular
normal JavaScript objects that are now in different origins?
On Wed, Jul 31, 2013 at 8:38 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
But does the html5 spec say anything about what is supposed
On Wed, Jul 31, 2013 at 8:38 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
But does the html5 spec say anything about what is supposed to happen?
Sure:
3.1.2 Security
*Ready for first implementations*
User agents must throw a
Mark S. Miller wrote:
I don't care about the document objects. What about access between
regular normal JavaScript objects that are now in different origins?
6.2.1Security
User agents must throw a|SecurityError
Mark Miller wrote:
When theincumbent script
http://www.whatwg.org/specs/web-apps/current-work/#incumbent-script'seffective
script origin
http://www.whatwg.org/specs/web-apps/current-work/#effective-script-originis
different than a|Document
I read it twice and I don't get it. Can you derive from this text what is
supposed to happen to a pointing relationship between two regular JS
objects from two different frames?
On Wed, Jul 31, 2013 at 9:51 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
I don't care about
On 7/31/13 7:39 PM, Mark S. Miller wrote:
But does the html5 spec say anything about what is supposed to happen?
Hixie punted on this and specced the current WebKit/Trident/Presto
behavior: the only security checks are on access to properties of
Document and Window (modulo the Location
[+ianh]
This seems like a bad bug in the html5 spec. Is there any public discussion
explaining why the currently speced behavior should be considered
acceptable? (Other than: It would be difficult to implement without
membranes.)
On Wed, Jul 31, 2013 at 10:26 PM, Boris Zbarsky
71 matches
Mail list logo
