IDE support?

[Brendan Eich]

On Sep 17, 2011, at 2:57 PM, François REMY wrote:

> The best way to avoid the "over-annotation" of codes is probably to teach users about WHEN or WHY they should add types guards. If you add the feature and don't explain what's her purpose and what specific scenarii it can solve, you'll get in trouble.
> 
> However, if you can coordinate with the whole community and publish a bunch of blog posts explaining how to "type efficiently", you'll get great results. But, in order to achieve that, all the implementations must be optimized for the same specific cases.

That all sounds great, but it's harder to do than you might think. My blog isn't read by everyone. People disagree with me anyway. The implementors won't all converge on the same economics in rapid fashion (they might over the long run, certainly for SunSpider :-P).


> JavaScripters are acustomated to a untyped language. They will not type everthing because we know how handy it's to rely on compiler optimization. The most critical part will be to teach cross-compiler makers and people learning JavaScript after beeing used to, let's say, Java.

Here be dragons.


> Anyway, another usage of type will be "automatic class instanciation from json data". For exemple, let's say I've a type defined like this :
> 
>   class A {
>       var myFirstField : B;
>       var mySecondField : B;
>       function areEqual() : bool {
>           if(myFirstField==null) { return mySecondField==null; }
>           if(mySecondField==null) { return false; }
>           return myFirstField.x == mySecondField.y;
>       }
>   };
> 
>   class B { int x; int y; }
> 
> You can do things like that :
> 
>   var myA = { myFirstField: {x:5, y:6}, mySecondField: {x:5, y:7} } as A;
>   console.log(myA.areEqual());

Syntax aside, this is all stuff we talked about in ES4 days, and the notion of initializing narrower types using object and array literals (with suffixed annotation, "as A" or ": A" or these days "::A" doesn't matter) is a natural.

The cosmic god-mode trade-off still lies ahead, and it bothers me. I would hate to make implementors' and bench-marketers lives easier if the net result for developers was negative.

/be