Re: Removing writable [Replaceable] properties

2012-12-21 Thread Boris Zbarsky

On 12/20/12 12:14 PM, Jeff Walden wrote:

WebKit gives the old behavior, but only for some of the listed properties -- it 
doesn't for status or name.


OK.  Given that, I think we should just go ahead and make these 
non-replaceable.  Given WebKit doesn't make "status" and "name" 
replaceable, the only place I'd expect possible compat problems is 
"opener", and I think it should be ok even there.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing writable [Replaceable] properties

2012-12-20 Thread Jeff Walden
On 12/20/2012 03:38 PM, Boris Zbarsky wrote:
> On 12/20/12 12:14 PM, Jeff Walden wrote:
>>  Setting it creates a shadowing property on window itself, using the exact 
>> value passed in.
>>
>>// Current Gecko
>>alert(typeof window.screenX); // number
>>window.screenX = "123";
>>alert(typeof window.screenX); // string, not number
> 
> Er...  no.  If you do that, you get number for the second alert, because you 
> did a qualified set.  That's the whole complication with these properties: 
> they behave differently for qualified and unqualified sets.

Oops, sorry, you're right.

I suppose I should mention for clarity that what I'm doing is trying to remove 
this difference.  There is no spec way to distinguish between a qualified and 
an unqualified access to a variable, to get or set it.  The [[GetP]] and 
[[SetP]] hooks that are part of ES6 (which is slightly reformulating this), and 
the [[GetOwnProperty]] and [[DefineOwnProperty]] hooks that are part of ES5, do 
not allow passing along qualification.  In the case of getting a property, all 
you get is the object, and the property name being looked up.  In the case of 
setting, you also get the value that goes along.  And if you're defining, you 
get a descriptor with a value and some set of property attributes.  The other 
operations, like [[HasProperty]] and [[HasOwnProperty]], also all take just the 
object and a property name/key.

> And the proposal here is to align with new IE and Opera?

Yes.

Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing writable [Replaceable] properties

2012-12-20 Thread Robert O'Callahan
Seems like a reasonable change to me, for the inner*, outer* and screen*
properties. I don't know about the others.

Rob
-- 
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing writable [Replaceable] properties

2012-12-20 Thread Boris Zbarsky

On 12/20/12 12:14 PM, Jeff Walden wrote:

 Setting it creates a shadowing property on window itself, using the exact 
value passed in.

   // Current Gecko
   alert(typeof window.screenX); // number
   window.screenX = "123";
   alert(typeof window.screenX); // string, not number


Er...  no.  If you do that, you get number for the second alert, because 
you did a qualified set.  That's the whole complication with these 
properties: they behave differently for qualified and unqualified sets.



   // Proposed Gecko
   alert(typeof window.screenX); // number
   window.screenX = "123";
   alert(typeof window.screenX); // number (setter coerces string->number, or 
the setter silently did nothing)

This is compatible with IE9 (standards or quirks mode -- and not in IE9 compat 
mode, and it seems not in older IE modes; I don't have IE10 to test) and Opera 
behaviors.  IE9 puts the accessor on Window.prototype, and Opera puts it on 
window, but there's no visible difference in behavior for getting or setting.

But there's still a supposed compatibility bugaboo to changing, because sites 
might have relied on the old behavior (notwithstanding that browsers are all 
over the map here)


So specifically, for unqualified sets right now Gecko and WebKit 
reconfigure the property to a data property, as do older IE, but not 
newer IE or Opera, right?


And the proposal here is to align with new IE and Opera?

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform