types

Steven Johnson stejohns at adobe.com
Thu Aug 14 13:58:56 PDT 2008


On 8/14/08 12:30 PM, "Brendan Eich" <brendan at mozilla.org> wrote:

> That allows sqrt("foo") to compute the square root of a NaN, which is
> a NaN.

Doh. Yeah. (Though, interestingly, the AS3 compiler will reject this in
strict mode as implicit coercion of unrelated types, although no runtime
error is generated.)  A better example would be

    // a must be Array
    function foo(a:Array) {}

    foo("uh-oh")

 
> For this reason, ES4 last year moved to avoid implicit conversions
> except among number types.

Good call.
 
 
> IIRC that's because AS3's strict mode (a static type checker) changes
> the rules to avoid the implicit conversion (from the standard or
> dynamic mode, which converts freely as you say). May be water under
> the bridge, but at least for ES4 we chose to get rid of the strict
> vs. standard implicit conversion difference, and require a number in
> both.

Yep. Consistency between the two is a better choice. But the concept is
still nice (statically determining that the code would always produce a
runtime error).
 
> There are pluses and minuses. We've all been saved by simple types in
> C, compared to assembly or pre-historic C which allowed int and
> pointers to convert, and treated struct member names as offset macros
> usable with any int or pointer. But JS is a higher level language,
> and one doesn't need to annotate types to avoid memory safety bugs.
 
True, but that's not the only reason to use type annotations, at least in
the context of AS3/ES4 -- they open up possibilities for early binding,
efficient storage decisions, etc that would be hard(er) to deduce otherwise.

> For numeric code, there can even be a de-optimizing effect if one
> uses int or uint in AS3, I'm told, because evaluation still promotes
> everything to Number (double). Is this right?

In the current Tamarin-Central VM this is the case, since we maintain ES3
numeric semantics for int and uint. However, there's some evidence that this
could be substantially improved by using integer operations and checking for
overflow (and reverting to double only in that case)... this was
experimented with in Tamarin-Tracing but I'm not sure if it's live or not. 




More information about the Es-discuss mailing list