Re: Should Decode accept U+FFFE or U+FFFF (and other Unicode non-characters)?

Reraising this issue... To briefly repeat: Decode, called by decodeURI{,Component}, says to reject %ab%cd%ef sequences whose octets "[do] not contain a valid UTF-8 encoding of a Unicode code point". It appears browsers interpret this requirement as: reject overlong UTF-8 sequences, and otherwi

Re: The Structured Clone Wars

On Thu, Jul 14, 2011 at 2:46 PM, Mark S. Miller wrote: > Ambiguities: > 1) When the says "If input is an Object object", I assumed it meant 'if the > input's [[Class]] is "Object" '. > 2) By "for each enumerable property in input" combined with "Note: This does > not walk the prototype chain.", I

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Jul 14, 2011, at 4:59 PM, Mark S. Miller wrote: > On Thu, Jul 14, 2011 at 3:00 PM, Allen Wirfs-Brock > wrote: > > On Jul 14, 2011, at 1:19 PM, Mark S. Miller wrote: > > Do you really think it makes sense to allow new properties to appear on > non-extensible objects? Really? > > Perhaps y

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Jul 14, 2011, at 4:59 PM, Mark S. Miller wrote: > On Thu, Jul 14, 2011 at 3:00 PM, Allen Wirfs-Brock > wrote: > > >> > > Implementations are free to add new built-in objects (see 4.3.28). Without > any stated requirements for such objects you have no guarantees. > > Quoting that sect

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Jul 14, 2011, at 4:59 PM, Mark S. Miller wrote: > Do you really think it makes sense to allow new properties to appear on > non-extensible objects? Really? > > Perhaps you do. Again, unless and until we get agreement to clean up these > (irregularities, inconsistencies, features, whatever yo

Re: Array.prototype.concat result length (ES5.1)

On Jul 14, 2011, at 2:14 PM, Mark S. Miller wrote: > Would we just be postponing all those same edge cases from 2**32 to 2**53? No, because you lose precision adding 1 to an index to get length after that. No bignums. /be > > On Thu, Jul 14, 2011 at 1:54 PM, Brendan Eich wrote: > On Jul 14,

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Thu, Jul 14, 2011 at 3:00 PM, Allen Wirfs-Brock wrote: > > On Jul 14, 2011, at 1:19 PM, Mark S. Miller wrote: > [...] > Absent other costs, that's a fine thing to want. But because of those > costs, it was never a goal of the proxies design. > > > I think several of us have been quite consiste

Re: The Structured Clone Wars

I think we should remove all the requirements around special handling of functions that can run script. It can definitely cause head aches for implementors, but as long as *any* script can run during the structured cloning then this is a problem we have to deal with anyway. The fact that scripts c

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Jul 14, 2011, at 3:00 PM, Allen Wirfs-Brock wrote: >> Host objects are part of the platform. A platform provider is free to >> violate any part of the spec they like, and there's nothing we can do about >> it other than to add tests to std test suites to make the violations obvious >> to the

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Jul 14, 2011, at 1:19 PM, Mark S. Miller wrote: > On Thu, Jul 14, 2011 at 12:19 PM, Allen Wirfs-Brock > wrote: > I think Mark and I are looking at Proxies from very different perspectives. > > Agreed. > > > I want Proxies to to useful to create a perfect implementation of anything > tha

Re: Array.prototype.concat result length (ES5.1)

Would we just be postponing all those same edge cases from 2**32 to 2**53? On Thu, Jul 14, 2011 at 1:54 PM, Brendan Eich wrote: > On Jul 14, 2011, at 12:35 PM, Allen Wirfs-Brock wrote: > > > What about the possibility of simply eliminating the range error and the > Uint32 restriction on the asso

Re: The Structured Clone Wars

Hmmm. This revision includes "except if obtaining the value of the property involved executing script". Now imagine writing a predicate for that in JS. Among native-only objects in ES5.1, you can do it by using the original Object.getOwnPropertyDescriptor, to first check if the property is an acces

Re: Array.prototype.concat result length (ES5.1)

On Jul 14, 2011, at 12:35 PM, Allen Wirfs-Brock wrote: > What about the possibility of simply eliminating the range error and the > Uint32 restriction on the association between array indexed properties and > the "length" property. Instead replace it with a ToInteger constraint. This > is ess

Re: The Structured Clone Wars

Also note that the current editor's draft http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data has some changes. Also there is some controversy about some of them http://www.w3.org/Bugs/Public/show_bug.cgi?id=12101 Something that isn't clear to me is which primordials ar

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Thu, Jul 14, 2011 at 1:19 PM, Mark S. Miller wrote: > On Thu, Jul 14, 2011 at 12:19 PM, Allen Wirfs-Brock > wrote: > >> I think Mark and I are looking at Proxies from very different >> perspectives. > > > Agreed. > > > >> I want Proxies to to useful to create a perfect implementation of anyth

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Thu, Jul 14, 2011 at 12:19 PM, Allen Wirfs-Brock wrote: > I think Mark and I are looking at Proxies from very different perspectives. Agreed. > I want Proxies to to useful to create a perfect implementation of anything > that be specified as a ES built-in object or that might be implemente

Re: The Structured Clone Wars

On Thu, Jul 14, 2011 at 12:46 PM, Mark S. Miller wrote: > At the thread "LazyReadCopy experiment and invariant checking for > [[Extensible]]=false" on es-discuss, > On Wed, Jul 13, 2011 at 10:29 AM, David Bruant wrote: > >> Hi, >> >> Recently, I've been thinking about the structured clone algorit

The Structured Clone Wars

At the thread "LazyReadCopy experiment and invariant checking for [[Extensible]]=false" on es-discuss, On Wed, Jul 13, 2011 at 10:29 AM, David Bruant wrote: > Hi, > > Recently, I've been thinking about the structured clone algorithm used in > postMessage > Along with Dave Herman < http://blog.moz

Re: Array.prototype.concat result length (ES5.1)

On Jul 14, 2011, at 10:39 AM, Brendan Eich wrote: > On Jul 14, 2011, at 10:04 AM, Allen Wirfs-Brock wrote: > >> This appears to be a (possible) specification bug that first occurs in ES3 >> and which was not corrected in ES5. >> >> I appears in concat and push. But no other algorithms. The pr

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Jul 14, 2011, at 10:47 AM, Brendan Eich wrote: > On Jul 14, 2011, at 10:38 AM, David Bruant wrote: > >>> In all the cases I can think of, where we want precisely the behavior of an >>> array, why not just use an array? >> Of course an array should be used. I think that the current question i

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Jul 14, 2011, at 10:38 AM, David Bruant wrote: >> In all the cases I can think of, where we want precisely the behavior of an >> array, why not just use an array? > Of course an array should be used. I think that the current question is > rather "can proxies as currently defined can fully emu

Re: Array.prototype.concat result length (ES5.1)

On Jul 14, 2011, at 10:04 AM, Allen Wirfs-Brock wrote: > This appears to be a (possible) specification bug that first occurs in ES3 > and which was not corrected in ES5. > > I appears in concat and push. But no other algorithms. The problem occurs > when when a length value is incremented and

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

Le 14/07/2011 18:57, Mark S. Miller a écrit : > On Thu, Jul 14, 2011 at 6:01 AM, David Bruant > wrote: > > > > If that's the question: > - > var a = Array(1,2,3,4); // a.length===4 > Object.preventExtensions(a); > cons

Re: Design principles for extending ES object abstractions

On Jul 14, 2011, at 12:00 AM, Luke Hoban wrote: > > I don't want to quibble about philosophical pedantry, but that's really all I > mean by my shyness about General Principles. They're strictly *harder* to > decide on than the problem at hand. It's too easy to lose focus and waste > time argui

Re: Array.prototype.concat result length (ES5.1)

(don't miss the second part of my response) On Jul 14, 2011, at 5:21 AM, Andrew Oakley wrote: > I'm not sure the Array.prototype.concat algorithm (§ 15.4.4.4) is quite > right. > > As far as I can see the length property of the result (A) is not > explicitly set anywhere in the algorithm so we a

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

On Thu, Jul 14, 2011 at 6:01 AM, David Bruant wrote: > Le 13/07/2011 20:52, Mark S. Miller a écrit : > > On Wed, Jul 13, 2011 at 8:38 AM, Allen Wirfs-Brock > wrote: > >> Hate to start another cycle of this, but if (trapping) proxies can't be >> set to [[Extensible]]: false, then they can't be

Re: [Harmony Proxies] LazyReadCopy experiment and invariant checking for [[Extensible]]=false

+ Mark to discuss ES5.1 invariants. > I'm working on an implementation. It will be independent from the > FixedHandler one. It should be possible to combine both easily though. > > I'll give a follow-up here when I'm done. So, here it is: https://github.com/DavidBruant/HarmonyProxyLab/tree/master/

Re: [Harmony Proxies] LazyReadCopy experiment and invariant checking for [[Extensible]]=false

Le 14/07/2011 16:23, Tom Van Cutsem a écrit : > Hi David, > > 2011/7/13 David Bruant > > > Hi, > > Recently, I've been thinking about the structured clone algorithm used > in postMessage > The browser has to do a copy of an object and pass it to the me

Re: [Harmony Proxies] LazyReadCopy experiment and invariant checking for [[Extensible]]=false

Hi David, 2011/7/13 David Bruant > Hi, > > Recently, I've been thinking about the structured clone algorithm used > in postMessage > The browser has to do a copy of an object and pass it to the message > receiving context. In some cases, if the object has a lot of properties, > it could be costl

Re: [[Extensible]]and Proxies (Was: Proxy.isProxy )

Le 13/07/2011 20:52, Mark S. Miller a écrit : > On Wed, Jul 13, 2011 at 8:38 AM, Allen Wirfs-Brock > mailto:al...@wirfs-brock.com>> wrote: > > Hate to start another cycle of this, but if (trapping) proxies > can't be set to [[Extensible]]: false, then they can't be used to > fully emul

Re: Array.prototype.concat result length (ES5.1)

I also reported it to es5-discuss https://mail.mozilla.org/pipermail/es5-discuss/2010-December/003851.html, and got " This is a bug in the spec." I think [[Put]]("length", {[[Value]]: n}, true) step should be inserted to the end of this(like, pop, push method), is it correct? On Thu, Jul 14, 2011

Array.prototype.concat result length (ES5.1)

I'm not sure the Array.prototype.concat algorithm (§ 15.4.4.4) is quite right. As far as I can see the length property of the result (A) is not explicitly set anywhere in the algorithm so we are relying on the [[DefineOwnProperty]] method of A to set the length for us when we add indexed propertie

Re: Type of property names, as seen by proxy traps

"tampered", not "hampered", of course... On 14 July 2011 12:52, Andreas Rossberg wrote: > Very much appreciated. Given all the nasty mutability in JS, I think > for the non-normative JS implementations you also might want to note > that it assumes that nobody has hampered with the primordial Obje

Re: Type of property names, as seen by proxy traps

Very much appreciated. Given all the nasty mutability in JS, I think for the non-normative JS implementations you also might want to note that it assumes that nobody has hampered with the primordial Object object. /Andreas On 14 July 2011 12:34, Tom Van Cutsem wrote: > Follow-up: I updated >

Re: Type of property names, as seen by proxy traps

Follow-up: I updated < http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics> with a more precise specification of the default behavior of all derived traps. This should also resolve the double-coercion issue with Object.keys. In summary: - for "has", "hasOwn" and "get" it's easy to fal

RE: Design principles for extending ES object abstractions

Well, I think I understand what you're getting at: there's a sense in which generators don't add the ability to do something that's *absolutely impossible* to express in ES5. OTOH, generators make it possible to express something that otherwise -- in general -- requires a deep tran