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

Re: Non-constructible constructors and Arrays

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 3 Aug 2011 10:24:09 -0700
Message-ID: <CABZUbM1S2tSVNLnLON85eZ_FBJxgcqfZZrP0gxYbsd8GZLcezA@mail.gmail.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
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>
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.

If you tag these methods as mutating non/mutating, any system using
them can "fail fast."
-- 
Garrett
Received on Wednesday, 3 August 2011 17:24:36 UTC

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