Suggestions for the proposed ByteArray in ES4

Brendan Eich brendan at mozilla.org
Thu Jan 18 10:39:25 PST 2007


On Jan 18, 2007, at 9:53 AM, Steven Johnson wrote:

> I think the concern was one of typing: given the expression [ 1, 2,  
> 3 ],
> what type is it, Array or ByteArray? ( Perhaps we could use an  
> explicit type
> annotation, e.g., [1,2,3]:ByteArray ... ) The point being that  
> Array and
> ByteArray aren't interchangeable (Array provides much more  
> functionality).

See previous message from me about Array methods being almost all  
generic, intentionally so since ES1. Would it break AS3's ByteArray  
to have it inherit from Array?

The current ES4 grammar can't parse ''[1,2,3]:ByteArray'', because it  
wants a structural array type after the '':''. I believe that's a  
bug, because we want to allow abstraction via defined type names, at  
least.  If that bug were fixed, then the question becomes: what is  
the meaning of the expression if the type after the : is a nominal  
one such as ByteArray?  In a definition, e.g. ''let b:ByteArray =  
[1,2,3];'' the meaning of the type annotation is to convert the  
initializer as if by the ''to'' operator (http:// 
developer.mozilla.org/es4/spec/chapter_6_types.html).

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.

> I suppose we could allow array literals to be coerced to ByteArray,  
> though,
> and it could probably be optimized at compiletime in many cases.

This all "just works", except for the optimization, if we provide a  
''to'' operator method.

(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]. 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.)

/be



More information about the Es4-discuss mailing list