2013/9/25 Boris Zbarsky bzbar...@mit.edu
On 9/25/13 3:47 PM, Mark S. Miller wrote:
Hi Boris, I don't understand what you mean by in general. I think the
SpiderMonkey use of cross-realm membranes is a great use case for
membranes, and I don't understand why they need any special logic at all
Le 26/09/2013 14:44, Anne van Kesteren a écrit :
On Thu, Sep 26, 2013 at 12:22 AM, Brendan Eich bren...@mozilla.com wrote:
Boris Zbarsky wrote:
The web _does_ in general rely on being able to apply methods from some
built-in (including DOM) prototype in one realm to objects from another
realm.
On 9/26/13 5:16 AM, Tom Van Cutsem wrote:
I believe the crucial part of why this works is because the built-ins
can recognize trusted, cross-realm proxies, from arbitrary other proxies.
Yes, agreed.
Answering MarkM's question of whether we can self-host such behavior, I
believe we can:
On 9/26/13 10:45 AM, David Bruant wrote:
Formulated differently: does the web has requirements making such
process isolation impossible?
Unclear.
The web has a requirement that if I have a pointer to a cross-origin
window win then doing win.name will find child windows of it with
name=name.
Mark S. Miller mailto:erig...@google.com
September 26, 2013 8:55 AM
I think we need to distinguish two senses of process when we ask this
question:
a) address space separation in the implementation
b) concurrency
#b would be a breaking semantic change, so I'm going to write that off
here.
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with direct proxies and
we have not been able to
Le 25/09/2013 12:01, David Bruant a écrit :
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with
Why does Date need private state? AFAICT, it only needs uniquely named
state. Why not do what we've done for many other bits of internal state
that doesn't need to be private: just name it with a unique symbol? This
doesn't work for all internal state of course, but it does seem it would
work for
On 9/25/13 5:18 AM, Tom Van Cutsem wrote:
The auto-unwrapping doesn't break membranes, because membranes never
expose direct references to built-in functions (they only expose wrapper
functions, which can still do whatever interposition they want before
calling the actual built-in).
I'd like
Le 25/09/2013 15:49, Mark S. Miller a écrit :
Why does Date need private state? AFAICT, it only needs uniquely named
state. Why not do what we've done for many other bits of internal
state that doesn't need to be private: just name it with a unique symbol?
yes (assuming unique symbols are a
On Sep 25, 2013, at 3:01 AM, David Bruant wrote:
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with direct proxies and we have
not
On Sep 25, 2013, at 6:49 AM, Mark S. Miller wrote:
Why does Date need private state? AFAICT, it only needs uniquely named state.
Why not do what we've done for many other bits of internal state that doesn't
need to be private: just name it with a unique symbol? This doesn't work for
all
Le 25/09/2013 17:59, Allen Wirfs-Brock a écrit :
On Sep 25, 2013, at 3:01 AM, David Bruant wrote:
I think it's important to have a generic solution to avoid having
magic (non-self-hostable) built-ins (but I don't have this solution).
I don't think there is one, based upon Direct Proxies.
On 25 September 2013 15:49, Mark S. Miller erig...@google.com wrote:
Why does Date need private state? AFAICT, it only needs uniquely named
state. Why not do what we've done for many other bits of internal state that
doesn't need to be private: just name it with a unique symbol? This doesn't
On Wed, Sep 25, 2013 at 7:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/25/13 5:18 AM, Tom Van Cutsem wrote:
The auto-unwrapping doesn't break membranes, because membranes never
expose direct references to built-in functions (they only expose wrapper
functions, which can still do
That's why I picked on Date. We need to distinguish formerly-internal
potentially-public state from genuinely private state. WeakMap is
(ironically) a great example of an abstraction whose internal state must
remain private.
On Wed, Sep 25, 2013 at 7:22 AM, David Bruant bruan...@gmail.com wrote:
On Wed, Sep 25, 2013 at 8:59 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Sep 25, 2013, at 3:01 AM, David Bruant wrote:
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
On 9/25/13 3:47 PM, Mark S. Miller wrote:
Hi Boris, I don't understand what you mean by in general. I think the
SpiderMonkey use of cross-realm membranes is a great use case for
membranes, and I don't understand why they need any special logic at all
-- beyond the logic expressed by their
Le 25/09/2013 22:00, Boris Zbarsky a écrit :
On 9/25/13 3:47 PM, Mark S. Miller wrote:
Hi Boris, I don't understand what you mean by in general. I think the
SpiderMonkey use of cross-realm membranes is a great use case for
membranes, and I don't understand why they need any special logic at all
Boris Zbarsky wrote:
The web _does_ in general rely on being able to apply methods from
some built-in (including DOM) prototype in one realm to objects from
another realm.
This goes back to the dawn of JS. You can set location on a reachable
frame or window, even if not same-origin.
20 matches
Mail list logo
