Re: Mootools and String.prototype.contains
On 13/10/12 11:47, David Bruant wrote: 2012/10/12 Geoffrey Sneddongsned...@opera.com On 12/10/12 14:50, David Bruant wrote: I was looking at Bugzilla and came across two bugs [1] [2] related to Mootools-based (only Mootools 1.2-) websites being broken by the inclusion of String.prototype.contains in SpiderMonkey. I don't think it's been brought to the list yet, though I think it's relevant. Given there were similar issues with Function.prototype.bind in the same release of Mootools, I'm inclined to let it slide: Mootools 1.2 already broke given ES5, and that was pushed through regardless. By intuition, I'd say there is much more code with mystring.contains than uses of myfunction.bind and so pushing .contains may have more impact than .bind did. But that's just an intuition. My memory was Mootools itself depended on bind, so it was significantly more that broke, thus my conclusion. Someone (probably me!) should check what it was that actually broke, exactly. :) -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mootools and String.prototype.contains
On 12/10/12 14:50, David Bruant wrote: I was looking at Bugzilla and came across two bugs [1] [2] related to Mootools-based (only Mootools 1.2-) websites being broken by the inclusion of String.prototype.contains in SpiderMonkey. I don't think it's been brought to the list yet, though I think it's relevant. Given there were similar issues with Function.prototype.bind in the same release of Mootools, I'm inclined to let it slide: Mootools 1.2 already broke given ES5, and that was pushed through regardless. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On __proto__ as a magical data property
On 18/07/12 21:28, Brendan Eich wrote: Ollie: IIRC, JSC used to do what Rhino still does (last I looked): specialize __proto__ in the compiler or runtime (but either way, ahead of property lookup). True? That's definitely not on the table. Accessor vs. magic data property is the high-order choice, which at the May TC39 meeting we made in favor of magic data property. This is the same as what Carakan had until recently (it was special-cased in both the compiler and property lookup, the latter needed to handle cases where it wasn't statically determinable). From my point of view, what we have now is entirely less powerful than what we had previously, having an accessor property that can be deleted and having a setter that cannot be accessed (set on the property descriptor is poisoned). The latter is mainly done for the sake of not having a context check in [[ProtoSetter]], as the strawman:__proto__ accessor alternative had — we simply don't have the context for most objects, and I loath the add the overhead of it. Making the setter inaccessible resolves the SES concerns without adding further overhead (excluding the one extra branch in Object.getOwnPropertyDescriptor) in code that does that does not use __proto__. One of the concerns raised before was mutating prototypes of host objects: this has always been possible in Carakan and hasn't caused any issues, so I don't see any reason to remove this capability. Given we've had issues before with the overridden [[Get]], [[Put]], etc. not special-casing everywhere correctly, I'd much rather minimize special-casing and use an accessor property. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On 07/06/12 21:12, Jason Orendorff wrote: On Thu, Jun 7, 2012 at 1:37 PM, Erik Arvidssonerik.arvids...@gmail.com wrote: I wrote a new strawman for Error stack which is now available in some form in all major browser (if betas are considered). http://wiki.ecmascript.org/doku.php?id=strawman:error_stack Feedback wanted. This isn't machine parseable in all cases, since the .message may contain newlines and can end with something like \n at ... Changing this in Firefox would affect any Firefox addons that use Error.stack, but maybe we can take that hit. It's not just Firefox addons that will break: GWT's output relies upon the exact format of Error.stack[1]. I know Google Wave depended upon this, and I believe other Google applications do too. As such, I'm somewhat dubious as to whether we can actually change the format that much without breaking sites. For reference, we support Error.stack (supposedly identical to SpiderMonkey in format, though obviously not) and Error.stacktrace (which is meant to actually be human readable). Originally, we had Error.stacktrace as Error.stack, but it just broke too much (we spoof UA on some Google sites by default, and have to choose whether to go down IE/Fx/WK code-path, and often all three rely upon non-standard behaviour). [1]: http://code.google.com/p/google-web-toolkit/source/browse/releases/2.4/user/src/com/google/gwt/core/client/impl/StackTraceCreator.java -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Legacy const
const is needed in non-strict/strict code, as well as in Harmony code, has historically been needed for web compatibility on non-IE code. Chakra interestingly doesn't support it. (May simply be a case of it being IE and not fed code that realizes upon it.) Either we should spec it, likely block-scoped in modules as it is now and function-scoped otherwise, or everyone should drop it. (I doubt that's feasible, though.) -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Legacy const, attempt 2 (Re: Legacy const)
I've just had it pointed out to me that my original email made little sense, so let's try again: const has historically been needed in non-strict/strict code for web compatibility on non-IE code (typically either down to server-side UA sniffing or just explicitly non-support of IE). IE still doesn't support it, which may suggest it's not needed for compatibility any more, but as far as I can tell removing it would break enough to make it infeasible. As such, we should spec it: likely block-scoped in modules, and function-scoped otherwise. We should only really not spec it if we can get everyone who currently supports it to drop it. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On 26/02/12 09:39, David Bruant wrote: Le 26/02/2012 01:23, Geoffrey Sneddon a écrit : I've basically implemented something close to what is attributed to Dave Herman on the wiki in Carakan now, albeit without the context check, though I agree it's a good idea. I wonder if it's web-compatible to disallow cross-context prototype chains (both through __proto__ and Object.create). What is asked to be disallowed is only changing the prototype with __proto__ in a cross-context manner. Creating cross-context chains with Object.create has not been discussed I think and should be fine... or not? Given an attacker from context A, a defender from context D (I'll use these letters to refer to the global object of each context). An attacker can create an object like - var maliciousProto = Object.create(D.Object.prototype); // Add whatever own properties to maliciousProto someObjectInD.__proto__ = maliciousProto - I was enthusiastic by Gavin Object.prototype ownership-based solution, but it seems that as long as an attacker has the possibility to create cross-context objects, an Object.prototype-based solution actually does not prevent anything. I don't think there's much in the way of a security risk here (given that if you have access to D anyway you can execute arbitrary code within it). Even if __proto__ has been deleted you can just create a new object someObjectInD with mailiciousProto through Object.create. The only reason to prefer to avoid cross-context prototype chains is one of elegance: in my view it seems somewhat inelegant, though the more I think about it the less I can justify that position. The one thing I would prefer, however, would be that the setter is optional (i.e., it is permissible to have __proto__ have just a getter or have both a getter and a setter, but not just a setter). I think that it's unrealistic since the web does use the setter as well. If the setter was standardized as optional, all implementations would implement it anyway. I was speaking to Jeff Walden a few or two back about this — both of us at least still live in hope of someday getting rid of the setter. As far as either of us are aware, there isn't much legacy for the setter, mostly concentrated within a few libraries, which hopefully we can evangelize it out of — and then re-evaluate where we are in a few years and see whether the legacy has decreased, and older versions of the libraries have gone. Being obliged per spec to implement the setter forever seems undesirable, if we can manage to get rid of the legacy. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On 13/02/12 17:55, Allen Wirfs-Brock wrote:
Let's try to get this back to concrete issues that I can incorporate into a
specification.
The current draft is at
http://wiki.ecmascript.org/lib/exe/fetch.php?id=strawman%3Amagic_proto_propertycache=cachemedia=harmony:draft_proto_spec_rev2.pdf
Gavin and Oliver seem to really want to use an accessor for
Object.prototype.__proto__
On the whole this is my preference too, as it practically eliminates
special-casing for the __proto__ property, which on the whole I'm in
favour of.
I've basically implemented something close to what is attributed to Dave
Herman on the wiki in Carakan now, albeit without the context check,
though I agree it's a good idea. I wonder if it's web-compatible to
disallow cross-context prototype chains (both through __proto__ and
Object.create).
Brendan has expressed a willingness to accepting under specify some the
Object.prototype.__proto__ property in ways that we normally wouldn't for
mandatory parts of the specification.
I could accommodate these two perspective by changing the first paragraph of
the draft B.3.1.1 to read:
The __proto__ property of the Object prototype property initially has the
attributes {[[Enumerable]]: false, [[Configurable]]: true}. The state of other
attributes and whether it is an accessor or data property is implementation
defined.
This would allow implementations to use either a data property or a access
property for Object.prototype.__proto__. However, the internal method
extensions are still needed in order to define the semantics in a manner that
allows either implementation approach to be used.
I'm with Mark on this: I'd much rather see there be (rough) consensus on
this than divergent implementations.
The one thing I would prefer, however, would be that the setter is
optional (i.e., it is permissible to have __proto__ have just a getter
or have both a getter and a setter, but not just a setter).
--
Geoffrey Sneddon — Opera Software
http://gsnedders.com
http://opera.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Feedback request: a ES spec. organization experiment
On 12/10/11 01:32, Allen Wirfs-Brock wrote: Which style do you think I should use in the specification? On the whole, I don't think it matters. I don't think it's really the right way to solve the problem (finding cross-referenced functions). What would be (far) better, IMO, is to link cross-references (i.e., so PutValue is a hyperlink to the PutValue definition). As for the changing document, I guess at least some (most of what is from ES5.1, for a start) is almost certainly going to say around, so that effort probably isn't a waste. (On a side-note, with the discussion of HTML, I wonder how hard it would be to write a print style-sheet targetting something like PrinceXML to cope with all the publication rules?) -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
__proto__ in Annex B (was: Re: Sep 27 meeting notes)
On 28/09/11 00:06, Waldemar Horwat wrote: Should we standardize __proto__ in Annex B? MarkM + a few others: Yes Waldemar, Doug: No Unless we have a definite plan that no ES.Next impl will support __proto__, then by all means don't standardize it. However, seeming the conclusion before was that not all use-cases of __proto__ are handled currently, once they are addressed in ES.Next, there will still be some transitional phase. I'd rather specify it in ES.Next, even if we do then agree to drop it in ES.(Next+1). That said about any transitional phase, if it turns out we can make it [[Writable: false]] in ES.Next, then all the better (thereby only providing a transitional phase for those who can already use Object.getPrototypeOf). -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ in Annex B
On 29/09/11 19:10, Brendan Eich wrote: On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote: On 28/09/11 00:06, Waldemar Horwat wrote: Should we standardize __proto__ in Annex B? MarkM + a few others: Yes Waldemar, Doug: No Unless we have a definite plan that no ES.Next impl will support __proto__, then by all means don't standardize it. It is a standard (de-facto), we were just talking about making a non-mandatory normative spec for it. That does carry some weight but not much more than the de-facto standard, IMHO. Well, de-jure standard is what I meant (even a non-mandatory one). However, seeming the conclusion before was that not all use-cases of __proto__ are handled currently, once they are addressed in ES.Next, there will still be some transitional phase. I'd rather specify it in ES.Next, even if we do then agree to drop it in ES.(Next+1). That said about any transitional phase, if it turns out we can make it [[Writable: false]] in ES.Next, then all the better (thereby only providing a transitional phase for those who can already use Object.getPrototypeOf). Making the spec break the existing use-cases won't make browsers break those case. We don't get free-lunch rewrites from busy/absent developers who used writable __proto__ some time in the past for content that is still in service. The spec can only do so much. It would be better to remove __proto__ once the horses have found the new, healthy vegetables that replace it, and only then (based on surveys, web scans a la the sawzall study Hixie did [1], etc.). Indeed. I'm not expecting browsers to change behaviour blindingly based upon the spec, but from what I can see the number of instances of people writing __proto__ breaks almost nothing, so it may be entirely possible to make it non-writable. But, in general, in any case like this, I'd say the spec should follow implementations, not the other way around. If browsers are still going to support it, we should spec it. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: this vs thi\u0073
On 21/06/11 00:50, Luke Hoban wrote: My read of the spec is that thi\u0073 is a ReservedWord and should not be allowed as an Identifer. So the following part of the examples quoted below should be an early error: var thi\u0073 = 42; The text in 7.6 seems to address this with: All interpretations of identifiers within this specification are based upon their actual characters regardless of whether or not an escape sequence was used to contribute any particular characters. There's also http://wiki.whatwg.org/wiki/Web_ECMAScript#Identifiers which states (after saying this is very rough): Identifiers containing escape sequences are not equivalent to fully unescaped identifiers in the case that, after fully unescaping identifier, it is a ReservedWord. In particular it is possible to create Identifiers that unescape to a reserved word so long as at least one character is fully escaped. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead) but it need not be the same character(s) as that originally used to create the identifier. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
On 18/03/11 20:05, Brendan Eich wrote: On Mar 18, 2011, at 9:20 AM, Oliver Hunt wrote: I believe the current hope is to kill off __proto__ as quickly as is possible. I'm not taking a position in this argument, this is just my current understanding. This makes it sound quick. There's no way to guarantee that. Also, to kill it we need replacements for the valid use-cases, assuming we agree on those. These replacements need to have the right fit as well as form, i.e., they must be usable. Here's my framework for thinking about deprecation and obsolescence of __proto__: 1. A get equivalent: Object.getPrototypeOf in ES5. 2. A define (initialize on a newborn and otherwise inaccessible object) equivalent: see Object.create, but people criticize it on usability grounds. So, see Allen's mail and the strawman he is championing: http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_meta 3. Ship in multiple browsers, so library authors can detect and start to use them. 4. Wait a decent interval to evaluate usability. 5. Announce removal of __proto__ in subsequent releases of those multiple browsers. 6. Evaluate market share of downrev browsers as those release dates approach. 7. If all looks good, remove __proto__, done. 8. Else goto one of the earlier steps, possibly adjusting specs and impls based on feedback and uptake. This is *not* going to be quick. Is there much to be gained by removing __proto__ entirely? IIRC the original proposal was just to change it to being [[Writeable]]: false. Sure, still having it around isn't as nice as removing it entirely, but the cost of removing it would appear to be fairly high (it's fairly widely used in a read-only sense, and getting all that content to change is a lot of work for IMO not that much gain). -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Codifying de-facto standards
On 27/10/10 21:38, Brendan Eich wrote: Is there consensus that this is defacto standard behavior that is needed for interoperability among browsers and that it should be incorporated into Harmony? I suspect this is a de-facto standard we should codify in Harmony. Thanks for bringing it up. How much of de-facto standards are going to be codified? What about things which aren't entirely interoperability implemented, but the basic premise is an absolute requirement for web compatibility (e.g., the recent thread on function hoisting). What about things which are needed for web compatibility, interoperability implemented, but disallowed in ES5/Strict (e.g., Function.arguments, Function.caller, octal escapes (which are defined differently to all impls as raised before ES5 was finalized), etc.)? I'd very much like to get to a point where you can implement something web compatible from the spec, which would mean defining things some don't like, and changing other definitions that people don't like either… At the moment, it's impossible to implement a fully compliant ES5 implementation without sacrificing web compatibility. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function.prototype.toString to discover function dependencies
On 16/09/10 04:04, Erik Arvidsson wrote: As far as I remember some Opera mobile versions don't return the code in Function.prototype.toString. A lot of JS frameworks today use the Function.prototype.toString to find references to super/base but they do fallback on slower paths if the toString method does not provide the code of the function. FWIW, there should be no difference between Desktop and Mobile with Carakan. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Copy/paste error in Array.prototype.reduce
Hey, In Array.prototype.reduce there exists the following text basically copy/pasted from Array.prototype.filter: The range of elements processed by reduce is set before the first call to callbackfn. Elements that are appended to the array after the call to reduce begins will not be visited by callbackfn. If existing elements of the array are changed, their value as passed to callbackfn will be the value at the time reduce visits them; elements that are deleted after the call to filter begins and before being visited are not visited. the call to filter is wrong, it should refer to the call to reduce. Array.prototype.reduceRight contains a similar typo. -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
