Re: Violations of internal method invariants?
On 7/31/14, 1:53 AM, Tom Van Cutsem wrote: If I understand correctly, the form DOM element's named input properties 'shadow' the actual JS properties defined on the DOM object. That certainly seems to be what some UAs do, yes. This seems bad. I'm not a DOM expert, but is it essential that the form elements have two distinct namespaces (the namespace for named input elements and for regular JS properties), or is this just a side-effect of how they happen to be implemented? That's an interesting question. Gecko has totally different behavior here (we don't allow the form's named inputs to shadow own properties of the form if someone managed to define those, but will throw if you try to define a property for whose name we already have a named input. And the Web IDL spec has yet another approach to this whole thing: It simply coerces configurable to true in its custom [[DefineOwnProperty]] for these sorts of objects (but keeps effectively separate namespaces). I believe that the one shared feature between Gecko, the spec, and the IE/Chrome implementation is that if you set a property foo on the form, then add an input with name=foo, then remove the input, the value you set initially will still be there. Actually, the same is true in Safari, as long as you don't observe form.foo while the input is in the form. Requiring a single namespace, such that adding an input and then removing it would make a previous property with the same name as the input go away, would actually be fairly annoying performance-wise, I suspect. In any case, I would be very interested in figuring out what sane (sane-enough?) behavior UAs are willing to converge on here so we can actually spec it If anyone has suggestions for what that behavior should be, I'd love to hear them. Since every UA except Gecko certainly needs to change _something_ here no matter what, seems like we might as well all change in the same direction. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Why using the size property in set
Hi everybody, I was reading the doc for the new Set method and something suprised me : Why Set uses the size method instead of the length property ? -- Maxime WARNIER ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why using the size property in set
Le 31/07/2014 09:25, Maxime Warnier a écrit : Hi everybody, I was reading the doc for the new Set method and something suprised me : Why Set uses the size method instead of the length property ? IIRC and with my own words length refers more to something that can be measured contiguously (like a distance or a number of allocated bytes, etc.) while size doesn't have this contiguous aspect to it. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Violations of internal method invariants?
On Thu, Jul 31, 2014 at 1:23 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Requiring a single namespace, such that adding an input and then removing it
would make a previous property with the same name as the input go away,
would actually be fairly annoying performance-wise, I suspect.
Really? There are web pages that add inputs to forms in a tight loop?
In any case, I would be very interested in figuring out what sane
(sane-enough?) behavior UAs are willing to converge on here so we can
actually spec it If anyone has suggestions for what that behavior
should be, I'd love to hear them.
Right Thing: I think [[PreventExtensions]] on these objects should
always return false. I think [[DefineProperty]] on these objects
should return false if Desc.[[Configurable]] is false or if it's
missing and would default to false. That'll cause Object.freeze(form)
and Object.defineProperty(form, x, {configurable: false}) to throw a
TypeError. Seems legit.
Alternative: Specify what Gecko does. Make non-configurable properties
on these objects shadow even the named getter.
At the moment, I don't see anything else that would preserve the
object invariants.
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why using the size property in set
This was intentional
Allen
On Jul 31, 2014, at 5:24 AM, Nathan Wall ww...@google.com wrote:
Also, whether this was intentional or not, I think it's nice for objects with
`length` properties to all have properties at indices from `0` to `length`
(so they work in the `Array.prototype` methods) making `'length' in foo` a
lazy-man's `isArrayLike`.
```js
var forEach = Function.prototype.call.bind(Array.prototype.forEach);
forEach('foo', function(u) {
console.log(u);
});
```
On Thu, Jul 31, 2014 at 7:21 AM, David Bruant bruan...@gmail.com wrote:
Le 31/07/2014 09:25, Maxime Warnier a écrit :
Hi everybody,
I was reading the doc for the new Set method and something suprised me :
Why Set uses the size method instead of the length property ?
IIRC and with my own words length refers more to something that can be
measured contiguously (like a distance or a number of allocated bytes, etc.)
while size doesn't have this contiguous aspect to it.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Violations of internal method invariants?
2014-07-31 15:43 GMT+02:00 Jason Orendorff jason.orendo...@gmail.com:
Right Thing: I think [[PreventExtensions]] on these objects should
always return false. I think [[DefineProperty]] on these objects
should return false if Desc.[[Configurable]] is false or if it's
missing and would default to false. That'll cause Object.freeze(form)
and Object.defineProperty(form, x, {configurable: false}) to throw a
TypeError. Seems legit.
+1. They key point is that [[DefineOwnProperty]] should not try to coerce
configurable:false to configurable:true. It should just reject such
property updates.
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Violations of internal method invariants?
2014-07-31 15:26 GMT+02:00 Jason Orendorff jason.orendo...@gmail.com: There's not a rule that says flat-out, If Desc.[[Configurable]] is false and [[DefineOwnProperty]](P, Desc) returns true, that counts as 'observing' the property P as a non-configurable property on the target. but if you take that as read, what WebIDL is doing here is banned. Note that steps 14-22 of 9.5.6 (Proxy#[[DefineOwnProperty]]) do some checks which enforce this rule. http://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-defineownproperty-p-desc Tom, can the prose be improved? What's the intent? The intent is indeed that if [[DefineOwnProperty]] returns true for a non-configurable descriptor, then the client can count on the property being defined *as a non-configurable property*. It would not be OK for a proxy to tamper with the descriptor that the client passed in (e.g. by coercing configurable to true) and then signalling success, which seems to be what WebIDL is doing here. The prose says: A property cannot be added as or modified to be non-configurable, if it does not exists as a non-configurable own property of the target object. Possibly we need to make more explicit the fact that added as non-configurable pertains to the original attribute state that the client passed in. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Violations of internal method invariants?
On 7/31/14, 9:43 AM, Jason Orendorff wrote: On Thu, Jul 31, 2014 at 1:23 AM, Boris Zbarsky bzbar...@mit.edu wrote: Requiring a single namespace, such that adding an input and then removing it would make a previous property with the same name as the input go away, would actually be fairly annoying performance-wise, I suspect. Really? There are web pages that add inputs to forms in a tight loop? Sure. Simple example: a page that has a table. The table is in a form and is used to organize and lay out the controls. The table has a few hundred rows, each with several controls in it. The page has UI to sort the table rows; it does this by reordering them in the DOM using insertion sort. This is not a hypothetical example, by the way; I've certainly profiled pages of this sort before. Right Thing: I think [[PreventExtensions]] on these objects should always return false. The Web IDL spec requires this already, fwiw: Platform objects implementing an interface that supports indexed or named properties cannot be fixed; if Object.freeze, Object.seal or Object.preventExtensions is called on one of these objects, the function MUST throw a TypeError. If there is an actual hook it can hook into now to do that, so much the better. I think [[DefineProperty]] on these objects should return false if Desc.[[Configurable]] is false or if it's missing and would default to false. This is not compatible with the HTML spec, sadly (and neither is the spec, as a result) for the following reason: HTMLDocument needs to be able to have a non-configurable own accessor property named location. It looks like Safari and Chrome do not implement this part of the spec (from https://www.w3.org/Bugs/Public/show_bug.cgi?id=19560), for what that's worth, but get the web compat behavior actually needed via not following the HTML spec for other parts of named access on Document. The simple thing here would be to return false unless the property name is one of the ones that Web IDL defines as unforgeable on the object. Alternative: Specify what Gecko does. Make non-configurable properties on these objects shadow even the named getter. This is needed for HTMLDocument, as long as it has a non-configurable location property. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Violations of internal method invariants?
On Thu, Jul 31, 2014 at 1:24 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/31/14, 9:43 AM, Jason Orendorff wrote: Right Thing: I think [[PreventExtensions]] on these objects should always return false. The Web IDL spec requires this already, fwiw: [...] If there is an actual hook it can hook into now to do that, so much the better. Great. Please pass along to the WebIDL editor(s) that this can be done by specifying that [[PreventExtensions]] returns false. I think [[DefineProperty]] on these objects should return false if Desc.[[Configurable]] is false or if it's missing and would default to false. This is not compatible with the HTML spec, sadly (and neither is the spec, as a result) for the following reason: HTMLDocument needs to be able to have a non-configurable own accessor property named location. If location is exempt from shadowing, then it can be exempt from the restriction too. That solves the problem, right? -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Violations of internal method invariants?
On 7/31/14, 2:47 PM, Jason Orendorff wrote: Please pass along to the WebIDL editor(s) that this can be done by specifying that [[PreventExtensions]] returns false. Excellent. https://www.w3.org/Bugs/Public/show_bug.cgi?id=26490 If location is exempt from shadowing, then it can be exempt from the restriction too. That solves the problem, right? Yes. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
[Strawman proposal] StrictMath variant of Math
I was looking at the number of complaints about the Math object, especially regarding the lack of required precision (refer to the thread Re: ES6 accuracy of special functions for a lengthy discussion on this). Because of this, I propose that a new object, StrictMath, should be added. This would be analogous to java.lang.Math (performance) vs java.util.StrictMath (accuracy). People could still define their own implementations if needed, though. Basic specs would be similar to the Math object, but with the following caveats: 1. Fixed-size integer methods such as Math.imul() don't need a StrictMath variant. 2. The input precision must be no more than a Float64 in size (depends on how this is spec'd, may not be necessary). 3. The output should have an error no greater than 1 ulp (the space between two adjacent, distinct floating point values, identical to the Java spec of an ulp). I don't see #2 staying if this is spec'd well, but the rest remain. Java's java.lang.StrictMath actually requires the fdlibm semantics and algorithm to be used for that class's implementations. java.lang.Math is closer to this spec in its own specification. -- Isiah Meadows ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Strawman proposal] StrictMath variant of Math
On Thu, Jul 31, 2014 at 5:16 PM, Isiah Meadows impinb...@gmail.com wrote: I was looking at the number of complaints about the Math object, especially regarding the lack of required precision (refer to the thread Re: ES6 accuracy of special functions for a lengthy discussion on this). Because of this, I propose that a new object, StrictMath, should be added. This would be analogous to java.lang.Math (performance) vs java.util.StrictMath (accuracy). People could still define their own implementations if needed, though. Basic specs would be similar to the Math object, but with the following caveats: 1. Fixed-size integer methods such as Math.imul() don't need a StrictMath variant. 2. The input precision must be no more than a Float64 in size (depends on how this is spec'd, may not be necessary). 3. The output should have an error no greater than 1 ulp (the space between two adjacent, distinct floating point values, identical to the Java spec of an ulp). I don't see #2 staying if this is spec'd well, but the rest remain. Java's java.lang.StrictMath actually requires the fdlibm semantics and algorithm to be used for that class's implementations. java.lang.Math is closer to this spec in its own specification. Note that, as mentioned in the ES6 accuracy of special functions thread, java.lang.Math actually specifies accuracy requirements. This differs from Javascript where there are no requirements. Math should specify some accuracy requirements and since the spec specifically mentions fdlibm, the accuracy of fdlibm should be the minimum requirement. As for the StrictMath, I would go one step further and say StrictMath must produce correctly rounded results for the special functions. This might have been unrealistic a few years ago, but take a look at crlibm http://lipforge.ens-lyon.fr/www/crlibm/ that implements the C99 special functions that are correctly rounded (and provably correct) and is also fairly efficient. One nice side effect of requiring correctly rounded results is that the spec doesn't have to specify the algorithm. There is one and only one correct answer, and implementors are free to do whatever they want to achieve it. And finally, if there is to be a package with sloppy accuracy requirements (or lack there of), it should not be named Math. Call it FastMath or SloppyMath or whatever as long as it's not Math. Math has certain connotations and sloppiness is not one of them. However, I feel that without some kind of spec, its utility is greatly diminished because every implementation will be sloppy to a different degree. Also as mentioned in the ES6 accuracy thread, the people who need sloppiness know what kind of sloppiness they can tolerate and will do their own, ignoring any FastMath library. -- Isiah Meadows ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
