- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 3 Aug 2011 10:24:09 -0700
- 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