Suggestions for the proposed ByteArray in ES4
jwalden at MIT.EDU
Wed Jan 17 20:46:46 PST 2007
What was the rationale for disallowing use of array literals for initializing a ByteArray? As described now, there exists no way to seed a ByteArray with values other than by using some host functionality to create it (or, of course, by manually assigning). There's nothing wrong with that, of course, but it does basically make creating large byte arrays within JS hard unless you use an array and loop over it to copy it (an eminently unsatisfactory solution). Brendan's suggestion of ByteArray.fromArray would help, but without some good reason not to steal array syntax I think it unnecessarily adds extra characters and typing.
ByteArray instances certainly don't need all 30-odd methods included in the AS implementation (especially since the thrust of the AS ByteArray is basically to act like an input/output stream). However, ByteArray does need some methods to actually be usable; assigning index-by-index is painful and ugly. I think it makes sense to copy /some/ of the methods over from Array to ByteArray, keeping in mind how ByteArray would actually be used.
* push, pop
Since the length property still has the magical behavior of the length property of an Array, ByteArray is clearly still intended to have a dynamic size. The alternatives of directly assigning to the relevant index or getting the last element and decrementing the length are more verbose and probably slower without a peephole optimization. (I don't see shift/unshift as being useful as often, and I don't see the likely increased implementation complexity as good either, if you were to try to make it reasonably efficient.)
There doesn't seem to be a way to combine ByteArrays together. concat returns a new Array and thus isn't the right name, but I think some similar, mutating functionality (type-dispatching push?) is needed here. (Note also that if it were implemented, ByteArray.prototype.push.apply would take an Array as its second parameter and thus wouldn't work here.) For example, in Mozilla I would find this useful with our stream-listener interface, which reads bytes from a stream by some count at a time. If I want to assemble the bytes into one array (or even must assemble consecutive ByteArrays together because the data being parsed is broken in the middle of a token in the stream's data format), a concatenation method is necessary to avoid meaning-obscuring loops. It might be good to make this method accept Arrays as well, but I'm not entirely sure.
* indexOf, lastIndexOf
Parsing data formats which use some form of lookahead (e.g. reading bytes of an HTTP header looking for CRLF) becomes easier and faster with indexOf. Other data formats with different structures (e.g. the zip format and its end-of-central-directory record) would want lastIndexOf.
A straight mapping of code points to characters in a string is simple and more useful than "[object ByteArray]" or similar.
I can see arguments for some of SpiderMonkey's array iteration extensions (some/every/map/filter/forEach) and for the other standard ES array methods, but I can't come up with a real-world use case for any of them and have thus left them off; someone else can come up with them if desired. Since most of the Array methods are generic anyway, I see no reason you couldn't copy them over using some Array.prototype.*.apply magic. Beyond the methods mentioned here, tho, I really don't think you need much more functionality most of the time.
One last suggestion: ByteArray should support slice notation, with the result referencing the original ByteArray (i.e., mutating the result of a slice of a ByteArray modifies the original) so long as the step is 1 and the slice is not a copying slice (copy = byteArray[:]). I'm not sure how referential ByteArrays should interact with push/pop/"concat"-like creature, either on the new ByteArray or on the original. Perhaps modifying the length of a dependent ByteArray forces a copy, with any elements which may have been removed from the original ByteArray replaced by 0? It'd be a little complicated, but it might work.
Rediscover the Web!
Reclaim Your Inbox!
More information about the Es4-discuss