On Apr 20, 2015, at 11:11 AM, Rick Waldron wrote:

> 
> 
> On Mon, Apr 20, 2015 at 1:45 PM Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 
> On Apr 20, 2015, at 9:38 AM, Jason Orendorff wrote:
> 
> > We're implementing `super` in Firefox, and ran across this surprising behavior:
> >
> >    class X {
> >        constructor() {
> >            Object.defineProperty(this, "prop", {
> >                configurable: true,
> >                writable: false,
> >                value: 1});
> >        }
> >        f() {
> >            super.prop = 2;  // overwrites non-writable property!
> >        }
> >    }
> >
> >    var x = new X();
> >    x.f();
> >    assertEq(x.prop, 2);  // passes
> >
> > In the spec, 9.1.9 step 4.d.i. is where `super.prop = 2` ends up, with
> > O=X.prototype.
> 
> 4.d.1 doesn't set the property, it just comes up with the property descriptor to use, if the `Receiver` does not already have a corresponding own property.
> 
> 5.c+5.e checks if the corresponding own property actually exists on the `Receiver`.  If it already exits then it does a [[DefineOwnProperty]] that only specifies the `value` attribute. This should respect the current `writable` attribute of the property and hence reject the attempt to change the value.
> 
> So, sounds like a FF bug to me.  Of course, there might also be a problem in the spec. that I'm blind to.
> 
> V8 has implemented the same behavior that Jason has reported. 
> 
> If it's determined that this behaviour is undesirable, implementations could agree to do something like: 

What!?  The behavior Jason described looks like it is  contrary to the specification.  Implementations that are not following the spec. have a bug.  Also, since apparently at least two implementations have this bug, it sounds like we really need to have test262 tests for the specified behavior. 

FWIW, I believe that once upon the time the spec. may have produced the results Jason is observing.  But that behavior was pretty clearly wrong, as a [[Set]] operations should not be ignoring the writability of the property whose value it is modifying.


> 
> 
> 14.5.1 Static Semantics: Early Errors
>   
>   (extend with...)
> 
>   ClassTail : ClassHeritage_opt { ClassBody }
> 
>   ClassBody : ClassElementList
> 
>   ClassElementList : ClassElement
> 
>   ClassElement : MethodDefinition
> 
>   ClassElement : static MethodDefinition
> 
>     - It is a Syntax Error if ClassHeritage is not present and HasSuperProperty of MethodDefinition is true.

This is nothing to do with class definition syntax.  This is about the semantics of the [[Set]] internal method.

allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150420/abafcaa0/attachment.html>

On Apr 20, 2015, at 11:11 AM, Rick Waldron wrote:

> V8 has implemented the same behavior that Jason has reported. 
> 
> If it's determined that this behaviour is undesirable, implementations could agree to do something like: 

What!?  The behavior Jason described looks like it is  contrary to the specification.  Implementations that are not following the spec. have a bug.  Also, since apparently at least two implementations have this bug, it sounds like we really need to have test262 tests for the specified behavior. 

FWIW, I believe that once upon the time the spec. may have produced the results Jason is observing.  But that behavior was pretty clearly wrong, as a [[Set]] operations should not be ignoring the writability of the property whose value it is modifying.

>     - It is a Syntax Error if ClassHeritage is not present and HasSuperProperty of MethodDefinition is true.

This is nothing to do with class definition syntax.  This is about the semantics of the [[Set]] internal method.