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