Suggestions for the proposed ByteArray in ES4

Jeff Walden jwalden at MIT.EDU
Thu Jan 18 21:43:54 PST 2007


Brendan Eich wrote:
> So given a ''function to ByteArray(v) {...}" in class ByteArray, the UI 
> issue Jeff raises would be addressed.  An implementation could optimize 
> if it knew the initializer was not referenced elsewhere.

This was basically the way I supposed conversion would happen, yes.  A bare array literal would still have type Array unless it was explicitly annotated as ByteArray.  (The optimization to not create the Array was also something I assumed would be possible.)


> (BTW, it seems verbose to have ''function to C() {...}'' in class C in 
> order to customize the ''to'' operator. I mean that the repeated class 
> name is unnecessary if ''to'' is a reserved identifier [and it seems 
> that it must be reserved in ES4; existing JS on the web uses "to" for 
> variable and parameter names, so there's no way around the 
> incompatibility here].

How is this different from |for each (var foo in x)| versus |for (var foo in x)|, where single token lookahead resolves the iterating-keys and iterating-values cases?  In this case if the token after 'to' is an identifier it's a conversion method, and if it's a left-paren it's a method.  The same holds for |var a = x to T;| versus |var a = x;|, and |var v to T = x| versus |var v = x| (can't find this syntax in wiki but didn't look hard -- from http://weblogs.mozillazine.org/roadmap/archives/2005/11/js2.html in case it's actually relevant).  Are there any others I've missed?

(This is not to say that I think introducing a context keyword is good.  I think I'd want it treated similar to the way let and yield are treated by SpiderMonkey, where using either as an argument or identifer turns off their use in the new ways, as an implementation-dependent option, but where they're still keywords in ES4 code.)


> If instead, the overriding form were ''static 
> function intrinsic::from(v) {...}'' then we wouldn't need the repeated 
> typename or the magic ''to'' prefixing it, following ''function''. On 
> the other hand, ''from'' opposing ''to'' is a little obscure.)

I hesitate to ask here and not start a different thread, but why does class C contain |function to C(v) { ... }| to specify the to operator for |var q = x to T;|, or do I misunderstand?  I'd have expected |function to T(v)| repeated for any T desired, with |function to *(v) { ... }| as a final specifiable fallback.  The way I understand it now, |function to C| is probably going to contain a series of if-else if-else statements for |v is T1|, |v is T2|, etc.


> mutation via a shared reference is a hazard.  Are you prematurely optimizing?

Possibly so in some situations, possibly no in others.  If I'm decoding a zip, have its bytes in a ByteArray, and have the index and size of a large compressed file within it, it would be convenient to be able to pass a slice rather than the ByteArray (presumably ByteArray as an object is passed by reference) and a start and end index (and also have to do this for all byte ranges in the data).  The latter is at least a workaround if ByteArrays are mutably sliced, and it's not entirely intolerable.  At the worst you could create a DependentByteArray class that wrapped a ByteArray instance and define enough operators to make their use transparent, I suspect.


Jeff

-- 
Rediscover the Web!
http://snurl.com/get_firefox

Reclaim Your Inbox!
http://snurl.com/get_thunderbird



More information about the Es4-discuss mailing list