July notes: copySlice --> copyWithin ??
allen at wirfs-brock.com
Wed Aug 14 11:03:28 PDT 2013
On Aug 13, 2013, at 6:50 PM, Brendan Eich wrote:
> Rick Waldron wrote:
>> On Tue, Aug 13, 2013 at 7:27 PM, Allen Wirfs-Brock <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
>> From the notes, it's unclear whether there was consensus on using
>> the name "copyWithin" in place of "copySlice". My recollection is
>> that "copyWithin" was generally preferred by those at in the
>> discussion. Does anyone else remember?
>> When I went to file this as a bug, I realized that we held off recording a consensus (waiting for Brendan's input), but we never came back to it.
> I will try to avoid missing even a day of TC39, it clearly has taken some toll! ;-)
> Given the in-place |this|-mutating update done by copyWithin, I'm ok with the name. But it seems to suggest "within current [0, length) bounds" -- i.e., no extension of the |this| arraylike. Yet it can of course extend.
I was working on the spec. for these functions (whatever, their names end up being) yesterday and I discovered that these requirements in the original strawman:
If end > this.length and this.length is read-only a Range error is thrown and no elements are modified.
If end > this.length and this.length is not read-only, this.length is set to end
If target + (end-start) > this.length and this.length is read-only a Range error is thrown and no elements are modified.
If target + (end-start) > this.length and this.length is not read-only, this.length is set to target+(end-start).
can't really be specified in a generic manner. The problem is that there is no generic way to express the concept of a "read-only length" as in the generic case, "length" may be an inherited accessor property and the "read-only-ness" is enforced by the accessor's set function. In fact, the length of typed arrays is specified approximately that way.
I see two alternatives, we could drop the "and no elements are modified" requirement and just do "strict" sets on length at the end of the algorithm (this is what most existing Array methods do). However, this potentially produces an observably ill-forned this object (indexed properties beyond the length).
The other alternative is to confine the operations to the current length so the fill/copy would stop when reaching the current length of the this object.
In other words, rather than saying:
new Array().fill("foo", 0, 42);
You would have to say:
The first alternative may be a bit easier to specify, but I think I prefer the second alternative.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss