Re: [FileAPI] File.slice spec bug

Darin's position is "leaning toward" not breaking compatibility with what Chrome has shipped for a while. That's one consideration. It can't be the only consideration, or there's no point having a discussion and whatever Chrome ships first is an instant standard.

When we talked to Kenneth Arnold of Google about a typed array method that was more subtly misnamed "slice", he quickly worked with other WebGL folks to rename it to "subarray". That in spite of some support for the typed array "slice" method having shipped in some beta releases (at least; not sure if any final releases supported slice).

The subtler differences between typed array's subarray (formerly named slice) and JS's Array slice:

(a) The subarray method returns a view of mutable ArrayBuffer data, its elements alias the elements of the typed array from which it came. This is the big reason to avoid using "slice".

(b)  While subarray takes (start, end) parameters and allows end to be omitted; and it handles negative indexes; it does not allow start to be omitted too, whereas JS (after Python) does.

http://www.khronos.org/registry/typedarray/specs/latest/
http://www.khronos.org/webgl/public-mailing-list/archives/1102/msg00028.html

The DOM is full of crazy inconsistency from insta-standards in the mid-'90s, starting with my DOM level 0 work. That is not a good pattern to repeat now that we have more balanced market actors and the benefits of hindsight. We should try to agree on less inconsistent APIs and prototype them, but no single prototype implementation can create a standard. Only interoperable de-facto standards can do that.

At this point we need to be completely concrete, no leaning one way or another:

0. Do nothing.

1. Should we change slice, possibly breaking Chrome-only content that detects it by name but does not test its functionality?

2. Should we rename slice, allowing Chrome to keep the old name for a while if it must?

Solution 0 just leaves a noxious inconsistency on two counts: length not end as the second parameter, the lack of negative index support. Is there another difference with Array slice (which comes from Python and is in Ruby too)? What about optionality of the arguments?

Doing 1 is simpler for future users who don't have to deal with the legacy that Chrome-only content might represent.

Doing 2 avoids breaking any such legacy, but may increase the cognitive load for users who see the legacy and the new renamed method.

What about negative indexes? Is there time to spec and implement these per Python/JS/Ruby?

Without negative index support, the case for 2 is stronger again.

If Blob slice returns an aliasing view onto mutable data instead of a copy, just as typed arrays' subarray method does, then the case for 2 is extremely strong.

I do not see any mutator methods in http://dev.w3.org/2006/webapi/FileAPI/, but with the typed array precedent I didn't want to assume.

I favor 1 if negative index and optional argument semantics can be made to match precedent, and assuming no way to mutate shared Blob/sub-Blob data.

If not, I suggest 2, with "subBlob" or a better name -- that one hurts due to the shifted-B, but "subblob" seems also bad for the run-together "bb".

/be

Received on Wednesday, 13 April 2011 01:00:20 UTC