W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: Non-constructible constructors and Arrays

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Wed, 3 Aug 2011 10:57:52 -0700
Cc: Cameron McCormack <cam@mcc.id.au>, Jonas Sicking <jonas@sicking.cc>, Alex Russell <slightlyoff@google.com>, public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>
Message-Id: <68EBD76C-4774-47A7-8E61-AF58EB1512ED@wirfs-brock.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>
On Aug 3, 2011, at 10:24 AM, Garrett Smith wrote:

> On 8/3/11, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
>> 
>> On Aug 2, 2011, at 4:47 PM, Cameron McCormack wrote:
>> 
>>> On 3/08/11 4:04 AM, Allen Wirfs-Brock wrote:
>>>> Well, it's inherent in the ES specification's algorithm for each
>>>> method whether or not it mutates its this value.  We might consider
>>>> adding a non-normative note that further identifies such methods as
>>>> mutating or non-mutating but that doesn't really add any additional
>>>> information that isn't already available to browser implementors.
>>> 
>>> It's probably "obvious" in some sense, but it's the kind of thing I don't
>>> really like to leave open to interpretation.
>> 
>> I won't argue one way or another about obviousness, but the ES51 spec is
>> certainly precise WRT which of these methods mutate and which don't. There
>> is no room for interpretation but of course erroneous readings are always
>> possible.
>> 
> Does [1].reverse() mutate the object that it's called on?
> Unambiguously, no, right? So you have methods that will throw
> sometimes and not others.

Sure it does.  algorithm lines 6.h..i, 6.h.ii, 6.i.i, 6.i.ii, 6.j.i, 6.j.ii all perform mutating calls upon the this value.  Whether or not  they are actually executed depends upon the actual length of the "array".  The mutating/non-mutating classification criteria for these methods should be whether or not the algorithm includes steps that directly perform mutating operations upon the this object.  It doesn't matter whether or not those steps are are not performed for some specific this object values. 

> 
> If you tag these methods as mutating non/mutating, any system using
> them can "fail fast."

We are just talking about specification, not implementation.  Nothing in my suggested specification technique prevents an implementation from fast failing.

We are really talking about whether I should add additional non-normaltive text to the ES5 spec. In general, we are moving away from using such text as it creates spec. maintenance problems and we have see cases where differences in expression between normative/non-normative text  creates confusion.  The non-normative text also has a tendency to receive less intensive reviews and  this can lead  to it diverging from what is stated in the normative text. 


Allen
Received on Wednesday, 3 August 2011 17:58:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC