Idea:
Additionally disallow redeclaration (I mean redeclaration not reassignment; eg.
by parameter name in parameter list or function identified by a name already in
in use) with different type in same function scope when code is executed in ES6
strict mode. (New strict mode rule.)
This
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
Before we add more unstratified traps, I'd like Tom and Mark to comment.
They've thought a lot about invariants to preserve even with proxies in
the picture, and also for non-proxies. And they have a use-case to test
against: SES.
Herby Vojčík wrote:
But this has some quirks to solve, like
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
12 matches
Mail list logo
