On Aug 13, 2008, at 11:24 PM, Neil Mix wrote:
>> I do get the idea that a consumer of an API is helped with some good
>> error messages. Sometimes I have public API functions of a library
>> that start something like
>>
>> function(a, b) {
>> /* begin debug */
>> isInt(a); // throws
>> isStr(b); // throws
>> /* end debug */
>> ...
>>
>> The debugging code is stripped when deploying for production for
>> better download and runtime performance.
Dating myself here: I had to deal with Fortran, long ago. Kernighan
and Plauger created a structured programming language based on
Fortran, which translated to Fortran: Ratfor ("Rational Fortran").
Not saying JS is Fortran, but really, unless it floats your boat, why
not improve the language directly so it can support, declaratively if
possible, things you have to do with hand tools and magic comments
and offline sanitizers and so on?
Those extra things may be necessary now, but not forever. And they're
not a good use of programmer time, even if the initial development
cost is sunk (see sunk cost fallacy).
>> Does type checking catch misspelling bugs?
It can, yes. Without some notion of an object type, var o = foo();
o.mispelled can't be caught (suppose foo returns {misspelled: 42}).
AS3 does this, even for unqualified references if you are within a
package. But see below.
>>> To the extent that there's static type checking available to catch
>>> errors early on, it's a huge productivity gain.
>>
>> Is Harmony type checking even going to be static?
>
> These are great questions that I don't know the answer to.
It's ironic that ES4 already dropped its optional static type
checker. The 'use strict' proposal that was circulated, which was the
subject of efforts at subsetting and unification with 3.1 folks, was
like Perl's "use strict" -- use good taste and sanity. It was not
AS3's static type + sanity checker.
I think the fear and hate around any whiff of static typing tained
ES4 -- I'm glad to get past it, with Harmony if not with our earlier,
unnoticed cuts.
> Clearly
> this needs time to sort out in committee. But I'll weigh in with an
> early opinion that the option to do static type checking in JavaScript
> would, IMO, be a very good thing.
Although ES4 dropped the optional static type checker, ActionScript
was going to keep its checker, hooked up via the toolchain IIRC.
There's nothing preventing such extensions, but I don't foresee the
committee specifying an optional checker. The runtime type system,
however, needs to be fully specified, and if it's done right, then
any static type checker will be a conservative partial evaluation of
some sort.
I've written that interoperation problems could result if different
browsers used different degrees of conservatism and partial
evaluation, but I don't expect static checker extensions in most
browsers, and I'm also not too worried about people testing in the
more lenient one where the stricter one has enough market share for
the interop failure to be a problem. The issue will be what works in
browsers with their dynamic type checking (whatever it ends up being).
Before we cut the type checker from ES4, we were wrestling with when
a browser might try to check. Code is loaded often; windows and
frames can reference one another; documents and script tags come and
go. Cormac suggested just checking when things seem stable or
quiescent, repeatedly, and issue warnings. Not your "must go to
editor, fix stupid error, and recompile" experience, but arguably a
better one than Java heads have.
/be
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
