Sorry if I was too dense in my reply so things weren't understood. I
don't know how to reply put things efficiently because without big
picture, isolated cherry-picks seem ridiculous and properly put big
picture is often tl;dr-ed.
Concrete replies below.
Allen Wirfs-Brock wrote:
On Jan 8,
Le 08/01/2013 22:59, Erik Arvidsson a écrit :
On Tue, Jan 8, 2013 at 4:46 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
One idea would be in the short term that implementations reliably
*always* throw when trying to wrap non-ECMAScript objects and play
with
Le 09/01/2013 06:57, Boris Zbarsky a écrit :
And specifically, it's not clear what the behavior should be when
there are two different scripted proxies for the same WebIDL object.
Say it's a DOM node. One of the proxies gets passed to appendChild.
When later getting that node out of the DOM
all this reminds me, hilariously, the Object.defineProperty case in
Internet Explorer 8 ... the infamous implementation that works only on
global and DOM objects. Here we have the opposite behavior, something so
powerful that could let us redefine W3C specs or eventually make them
consistent
Le 31/12/2012 13:43, Tom Van Cutsem a écrit :
Hi David,
I generally support this view, although it may be too restrictive to
completely disallow non-standard exotics.
Instead, I would be happy if we could just state that non-standard
exotics are expected to uphold the invariants of the ES6
Le 09/01/2013 14:55, Andrea Giammarchi a écrit :
all this reminds me, hilariously, the Object.defineProperty case in
Internet Explorer 8 ... the infamous implementation that works only on
global and DOM objects. Here we have the opposite behavior, something
so powerful that could let us
On 1/9/13 5:24 AM, David Bruant wrote:
When later getting that node out of the DOM with .firstChild, what
should be handed back? The proxy that was passed in, the JS object
that proxy was wrapping, something else (e.g. an exception is thrown)?
The principle of least surprise would say the
only part I am slightly skeptical is that if developers cannot use
proxies with DOM nodes there's really not much to wait for ... they'll not
use them, end of the story.
If you mean waiting for developers to complain same way I did ... oh
well, I think is just a matter of time. I'll be here that
On Wed, Jan 9, 2013 at 9:07 AM, David Bruant bruan...@gmail.com wrote:
The current situation is that ES folks would like to impose some
restrictions on how the language can be extended, especially when it comes
to objects. To the possible extent (and it looks possible), the limits
would be
On Tuesday, January 8, 2013, Tab Atkins Jr. wrote:
On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi
andrea.giammar...@gmail.com javascript:; wrote:
So, I am playing with FF 18 and I have this behavior:
var a = new Proxy([], {});
console.log(a instanceof Array); // true
On Tue, Jan 8, 2013 at 11:54 PM, Brendan Eich bren...@mozilla.com wrote:
Boris and I talked more 1:1 -- it is not clear when a direct proxy can be
safely cast to its target. The internal proxies Gecko uses are known
implementations where this is safe (with a security check). An arbitrary
When later getting that node out of the DOM with .firstChild, what
should be handed back? The proxy that was passed in, the JS object
that proxy was wrapping, something else (e.g. an exception is thrown)?
The principle of least surprise would say the proxy that was passed in
That's
On 1/9/13 11:30 AM, François REMY wrote:
However, this second problem is not related to the DOM but to
globally accessible variables.
Well, right, but the DOM sort of forces the problem on us because of
window.document.
No membrane system can be secure through global variable access, so
we
Le 08/01/2013 22:23, Tab Atkins Jr. a écrit :
Meanwhile, there is unforgeable magic
behind DOM objects, and nothing we can really do about it.
Do you have examples? Besides document.all being falsy, everything seem
to be emulable with ES6 proxies.
David
Le 09/01/2013 16:02, Boris Zbarsky a écrit :
On 1/9/13 5:24 AM, David Bruant wrote:
When later getting that node out of the DOM with .firstChild, what
should be handed back? The proxy that was passed in, the JS object
that proxy was wrapping, something else (e.g. an exception is thrown)?
The
On 1/9/13 12:13 PM, David Bruant wrote:
There is some data associated with the object. Whether it's a (private)
property or a map entry is an implementation detail
...
Choosing symbols or a weakmap would make a huge difference in how proxy
replacement would react to DOM algorithms.
Then it's
I'm uncomfortable with the blurring of the boundary between specification and
implementation that I see in this thread.
Proxy is the only standard extension mechanism provided by ES6 for defining
non-standard exotic objects. If non-proxy based non-standard exotic objects
exist within an
On Jan 9, 2013, at 7:24 AM, Brandon Benvie wrote:
On Wed, Jan 9, 2013 at 9:07 AM, David Bruant bruan...@gmail.com wrote:
The current situation is that ES folks would like to impose some restrictions
on how the language can be extended, especially when it comes to objects. To
the possible
Le 09/01/2013 19:43, Boris Zbarsky a écrit :
On 1/9/13 1:23 PM, David Bruant wrote:
What happens if unknownPrivateSymbol throws?
I'm not sure yet. My guess is that the error should be propagated
So just to make sure we're on the same page here... Say I have a
proxy for a div and I put it
On 1/9/13 2:45 PM, David Bruant wrote:
Debattable. Here, there is no need to work with private state. The
nodeType and tagName and parentNode (all public) are enough to do the
matching I think.
No, because script can override them but matching needs to not depend on
that, right?
So the
David ? You said: It could still make sense to wrap a DOM Node with a
proxy to perform [[Get]] and [[Set]], etc. but definitely not put it in the
DOM tree.
so this is the current scenario ... now, can you explain me a single case
where you would need that? If you can't use the DOM node then why
Last, but not least, even offline DOM proxies are pointless, here another
example without putting them in the DOM
var p = new Proxy(
document.createElement(p),
{}
);
try {
p.appendChild(
document.createElement(span)
);
} catch(o_O) {
console.log(o_O.message);
}
try {
Le 09/01/2013 20:30, Allen Wirfs-Brock a écrit :
David seems to be primarily concerned about people who are writing specs. for
non-standard exotic objects (eg, W3C/WebIDL-based spec. writers) rather than
implementors of such objects.
I am indeed. When there is a spec, implementors only have
On Jan 9, 2013, at 1:56 PM, David Bruant wrote:
Le 09/01/2013 20:30, Allen Wirfs-Brock a écrit :
...
I don't see any need for an intermediate proxy representation or for
attempting to limit non-proxy based extension mechanisms. However, if Proxy
is not sufficiently powerful to support
Le 09/01/2013 21:30, Andrea Giammarchi a écrit :
David ? You said: It could still make sense to wrap a DOM Node with a
proxy to perform [[Get]] and [[Set]], etc. but definitely not put it
in the DOM tree.
so this is the current scenario ... now, can you explain me a single
case where you
Le 09/01/2013 21:57, Andrea Giammarchi a écrit :
Last, but not least, even offline DOM proxies are pointless, here
another example without putting them in the DOM
What's an offline DOM Proxy?
var p = new Proxy(
document.createElement(p),
{}
);
try {
p.appendChild(
That's what you
do you have any example of what you are saying? all my examples fail and I
don't understand other use cases.
As you said, if a Proxy should be undetectable a broken Proxy that cannot
be used is a pointless object full of inconsistency in the environment,
IMHO.
Is this the decision then? Let the
forgto this: yes, offline DOM node means a DOM that is not part of the live
DOM tree ... that is, indeed, disconnected, offline, no CSS, no repaint, no
reflow, nothing ... is offline. Isn't this term good enough? I thought that
makes sense
On Wed, Jan 9, 2013 at 2:57 PM, Andrea Giammarchi
This was basically what I was getting out, even if it was wrong in the idea
of using those specific internal methods rather than the higher level
methods you describe. Proxies are better than the completely magical
implementations that were used in the past, in that they will end up, by
default,
29 matches
Mail list logo
