July notes: copySlice --> copyWithin ??
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.
In contrast, "fill" takes optional slice parameters but has a short name. Perhaps we would be better with either
copy : fill :: copySlice : fillSlice
Thoughts? Naming is hard, let's not rush it. One more round of bikeshed paint-color debate!
FWIW, the reasoning against copySlice during the meeting was that the name suggests a copy would be returned of the slice of the array, which is not what it does. fillSlice seems to suggest you fill a slice with an array passed as argument (rather than something taken from the array).
copySlice/copyWithin is similar to the subset assignment operation in R, eg. vec[4:6] <- vec[1:3]
Array.prototype.subset(target = 0, start = 0, end = this.length)?
On Aug 13, 2013, at 6:50 PM, Brendan Eich wrote:
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:
fill
- 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
copySlice
- 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:
new Array(42).fill("foo");
The first alternative may be a bit easier to specify, but I think I prefer the second alternative.
Rick Waldron wrote:
copySlice/copyWithin is similar to the subset assignment operation in R, eg. vec[4:6] <- vec[1:3]
Didn't know you were an R hacker :-).
Array.prototype.subset(target = 0, start = 0, end = this.length)?
These names make my eyes itch.
I wonder if we are better off with just copy (and fill)?
On Wed, Aug 14, 2013 at 4:49 PM, Brendan Eich <brendan at mozilla.com> wrote:
Didn't know you were an R hacker :-).
More like an R beginner that had to confer with a real R hacker ;)
These names make my eyes itch.
I wonder if we are better off with just copy (and fill)?
I'm very much with you in the short-name-to-the-point camp, but the general opposition was that "copy" (alone) sounded more like a method that returned a "copy". I argue that "copy" is not incorrect—it's just not an overlyExplicitMethodName (a good thing).
The name copy matches my intuition for the behavior described, as
informed by the shell command cp source target and other precedents. I
would expect clone to return a deep copy, as in Object.clone(object, depth=Infinity, memo=Map()), informed by the Java precedent, and I would
not be perturbed by copy and clone coexisting as such.
I've seen libraries in other languages that name this kind of function 'blit'. Somewhat retro, but not too bad.
Re rwldrn/tc39-notes/blob/master/es6/2013-07/july-23.md#42-add-fill-and-copyslice-methods-to-arrayprototype-and-typed-arrays
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?