super.prop assignment can silently overwrite non-writable properties

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Apr 21 01:53:40 UTC 2015


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

> 
> 
> On Mon, Apr 20, 2015 at 2:31 PM Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> On Apr 20, 2015, at 11:11 AM, Rick Waldron wrote:
> 
>> 
>> 
> 
>>     - 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.
> 
> I understand that, but it struck me as _very_ strange that class with no class heritage could be allowed to have super.foo(), super.foo=2, but not super(). Did I miss something obvious? What is wrote is certainly heavy handed, but not more so than what the spec already does with HasDirectSuper when ClassHeritage is not present. Having just written many tests* for the early errors that will result when HasDirectSuper returns true, it seemed subjectively strange to me that this syntax would even be allowed. I suspect I'm missing something that explains why SuperProperty is allowed where SuperCall is not. 

remember, `super.x` (LHS or RHS) is a completely different operations than `super()`.  The former is semantically a [[Get]] or [[Set]] operation while the latter is a [[Construct]].  Completely different things that happen to both use the same keywords

'super.x' is allowed in any concise method, including those defined in object literals.  `super()` is only allowed in class constructors of classes that include a ClassHeritage.

Allen


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


More information about the es-discuss mailing list