New ES6 strawman: Array.prototype.fill and Array.prototype.move
On Jun 23, 2013, at 21:21 , Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
See strawman:array_fill_and_move for a strawman proposal for two new Array methods. These are proposed for inclusion in ES6.
Array.prototype.move = function move(target=0,source=0, count=this.length-source) Is the case of moving trailing elements somewhere else very common? If not, then I’d define the parameters in this order: source, count, target. Rationale: easier to memorize.
Axel Rauschmayer wrote:
On Jun 23, 2013, at 21:21 , Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
See strawman:array_fill_and_move for a strawman proposal for two new Array methods. These are proposed for inclusion in ES6.
Array.prototype.move = function move(target=0,source=0, count=this.length-source) Is the case of moving trailing elements somewhere else very common? If not, then I'd define the parameters in this order: source, count, target. Rationale: easier to memorize.
No, assignment-expression LHS/RHS (target/source) order precedent wins for memorization (see Object.extend precedent, strcpy, memcpy, etc.).
Allen: where is the Khronos draft spec on move? I can't find it.
Array.prototype.move = function move(target=0,source=0, count=this.length-source) Is the case of moving trailing elements somewhere else very common? If not, then I’d define the parameters in this order: source, count, target. Rationale: easier to memorize.
No, assignment-expression LHS/RHS (target/source) order precedent wins for memorization (see Object.extend precedent, strcpy, memcpy, etc.).
That makes sense, thanks!
I was thinking System.arraycopy, which may not a good precedent: docs.oracle.com/javase/6/docs/api/java/lang/System.html#arraycopy(java.lang.Object, int, java.lang.Object, int, int)
Axel Rauschmayer wrote:
Array.prototype.move = function move(target=0,source=0, count=this.length-source) Is the case of moving trailing elements somewhere else very common? If not, then I’d define the parameters in this order: source, count, target. Rationale: easier to memorize.
No, assignment-expression LHS/RHS (target/source) order precedent wins for memorization (see Object.extend precedent, strcpy, memcpy, etc.).
That makes sense, thanks!
I was thinking System.arraycopy, which may not a good precedent: docs.oracle.com/javase/6/docs/api/java/lang/System.html#arraycopy(java.lang.Object, int, java.lang.Object, int, int)
You lost me at "oracle.com/java..." :-P.
Brendan Eich wrote:
You lost me at "oracle.com/java..." :-P.
Joking aside, the weaker (source, target) order-precedent is from bcopy(3) in BSD Unix. I don't know for sure, and the signatures differ in other ways, but bcopy may have influenced Java's System.arraycopy design.
Allen Wirfs-Brock wrote:
See strawman:array_fill_and_move for a strawman proposal for two new Array methods. These are proposed for inclusion in ES6.
I updated the wiki:
Discussion
Q: Does anyone know of a rationale for why (start, end) might be a better design pattern than (start, count) for such operation?
A: Array.prototype.slice uses (start, end) where end is a fencepost to facilitate looping over half-open ranges within a larger range. Spec'ing count requires subtracting next_start - end, gratuitously. Also, consistency with slice and range APIs matters. This should be considered carefully in the design.
There isn't one. It came up in discussions with Kenneth Russell and Dave and I agreed that we would try to get it into ES6 rather than having him invent something.
On Jun 23, 2013, at 1:36 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
See strawman:array_fill_and_move for a strawman proposal for two new Array methods. These are proposed for inclusion in ES6.
I updated the wiki:
Discussion
Q: Does anyone know of a rationale for why (start, end) might be a better design pattern than (start, count) for such operation?
A: Array.prototype.slice uses (start, end) where end is a fencepost to facilitate looping over half-open ranges within a larger range. Spec’ing count requires subtracting next_start - end, gratuitously. Also, consistency with slice and range APIs matters. This should be considered carefully in the design.
Yes, both start,end (slice) and start,count (splice) currently appears in Array methods so it isn't obvious which precedent to follow for best consistency. I could go either way. It would be nice to have a utilitarian-based argument for one or the other. Search result was it because of the -1.
Allen Wirfs-Brock wrote:
On Jun 23, 2013, at 1:36 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
See strawman:array_fill_and_move for a strawman proposal for two new Array methods. These are proposed for inclusion in ES6. I updated the wiki:
Discussion
Q: Does anyone know of a rationale for why (start, end) might be a better design pattern than (start, count) for such operation?
A: Array.prototype.slice uses (start, end) where end is a fencepost to facilitate looping over half-open ranges within a larger range. Spec’ing count requires subtracting next_start - end, gratuitously. Also, consistency with slice and range APIs matters. This should be considered carefully in the design.
Yes, both start,end (slice) and start,count (splice) currently appears in Array methods so it isn't obvious which precedent to follow for best consistency.
The only place anything like (start, count) occurs is Array.prototype.splice, where count is deleteCount. There, the operation is destructive so one cannot update start in a larger loop over slices to the end (start + deleteCount), since that will skip further elements after the deleteCount ones that were removed.
So there is no precedent for (start, count) in non-destructive methods, and there is no utility in (start, end) for the destructive one.
I could go either way.
Nope! :-P
It would be nice to have a utilitarian-based argument for one or the other.
You have one here, from me.
Here's another thing, raised on twitter: the "move" name and metaphor is wrong. C++ has move semantics (so does Rust). The old memmove chestnut (required once upon a time instead of memcpy when source and target overlap) is misnamed. We should beware broken precedent -- remember Ken Thompson saying he would have spelled creat with a second e if he had Unix to do all over ;-).
Brian Kardell suggested copyRange. Not bad, but I prefer copySlice, it reinforces the (start, end) pattern.
Search result was it because of the -1.
Sorry, I don't know what you mean here.
On Jun 23, 2013 5:12 PM, "Allen Wirfs-Brock" <allen at wirfs-brock.com> wrote:
On Jun 23, 2013, at 1:36 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
See strawman:array_fill_and_movefor a strawman proposal for two new Array methods. These are proposed for
inclusion in ES6.
I updated the wiki:
Discussion
Q: Does anyone know of a rationale for why (start, end) might be a
better design pattern than (start, count) for such operation?
A: Array.prototype.slice uses (start, end) where end is a fencepost to
facilitate looping over half-open ranges within a larger range. Spec’ing count requires subtracting next_start - end, gratuitously. Also, consistency with slice and range APIs matters. This should be considered carefully in the design.
Yes, both start,end (slice) and start,count (splice) currently appears
in Array methods so it isn't obvious which precedent to follow for best consistency. I could go either way. It would be nice to have a utilitarian-based argument for one or the other. Search result was it because of the -1.
allen
2013/06/23 20:31/
/be
es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss
I would like to propose that .move() smells funny. It implies things that are not so. It actually copies, and, while .copyRange suggestion from the wiki is better, it really -feels- like .copySlice() which answers the args question as well.
On Sun, Jun 23, 2013 at 1:36 PM, Brendan Eich <brendan at mozilla.com> wrote:
Q: Does anyone know of a rationale for why (start, end) might be a better design pattern than (start, count) for such operation?
A: Array.prototype.slice uses (start, end) where end is a fencepost to facilitate looping over half-open ranges within a larger range. Spec’ing count requires subtracting next_start - end, gratuitously. Also, consistency with slice and range APIs matters. This should be considered carefully in the design.
In sane designs, start/end is better because you can specify negative indexes for either argument. Very useful. There is no analog of this for start/count.
Also, I use .slice() a lot, and consistency with that would be great. Inconsistency between start/end and start/count is one of the (many) reasons I hate PHP.
Brian Kardell suggested copyRange. Not bad, but I prefer copySlice, it reinforces the (start, end) pattern.
Actually, Kenneth Russell was first with copyRange...
But I also prefer copySlice and that implies that using start,end just like slice.
Search result was it because of the -1.
Sorry, I don't know what you mean here.
myArray.copySlice(toSpot,myAray.indexOf(startMarker), indexOf(endMarker));
indexOf fails with -1
Thanks, I added to the Answer:
Discussion
Q: Does anyone know of a rationale for why (start, end) might be a better design pattern than (start, count) for such operation?
A: Array.prototype.slice uses (start, end) where end is a fencepost to facilitate looping over half-open ranges within a larger range. Spec'ing count requires subtracting next_start - end, gratuitously. Also, consistency with slice and range APIs matters. This should be considered carefully in the design.
Furthermore, as Tab Atkins reminds on es-discuss, (start, end) supports negative indexes for both arguments (measured from length).
See strawman:array_fill_and_move for a strawman proposal for two new Array methods. These are proposed for inclusion in ES6.
These are motivated because the current Khronos Typed Array spec. maintainers what to make comparable operations available for TypedArrays while in ES6 we are trying to integrate TypedArrays with Array as much as possible. If they are going to be added for TypedArray, it is better for ES6 to added them now to Array and make them also available on TypedArray just like we are doing with all the other applicable Array.prototype methods.
If we don't define these in ES6, something like them is likely to show up in browsers only for TypedArrays and whatever that is might not be designed to be generalizable to ordinary ES Arrays.