ncannasse at motion-twin.com
Thu Jun 22 11:35:18 PDT 2006
> But I've also heard a credible argument during the design process: that
> the majority of JS code on the web is tiny little fragments, one liners,
> often fragments that only run zero or one times, and sometimes running
> on a cell phone. Keeping the "defaults" easy to compile is a priority
> for at least some of the language implementers. This means dataflow
> algorithms are unappealing: local expression-type inference is about all
> we want to pay for. We do not want to reimplement Java's definite
> assignment rules or similar.
Definite assignement would surely be the best way to ensure that a "T"
(or "T!") variable is correctly assigned. The two other ways to ensure
type-safety of these variables are :
a) forbid "var" declaration without an initialization expression. This
is a form of very strict definite assignement since no delay is even
b) have a runtime error. That's not what I would call "type-safety"
since it's just a kind of Null Pointer Exception just a bit before the
pointer is actually accessed.
From what I've seen, ES4 will not target the user that just want to
open a popup on his website or do some basic form validation. But when
you start using the type system, you should be able to rely on it.
Since you're not going the type-inference way, accessing strictly-typed
API with untyped code should not cause any problem, unless the user pass
an explicit "null" value where an not-nullable instance is required.
Or maybe I forgot something ?
More information about the Es4-discuss