Optional argument types

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Sep 25 09:19:41 PDT 2012


then how about forgetting ducks and classes, going typeof without implicit
cast?

function doStuff(i:number, key:string, u:undefined, b:boolean,
fn:function):object {}

where `null` will still be under the object type.

Would this be a decent compromise or a pointless effort for no benefits?


On Tue, Sep 25, 2012 at 5:12 PM, Brendan Eich <brendan at mozilla.org> wrote:

> John Lenz wrote:
>
>> that should have been "unrelated structures can look the same".
>>
>
> Right. Robert O'Callahan mocks this as "structural types are about field
> names, nominal types are about class names".
>
> Clearly, "duck typing" structural protocols (iteration in ES6) have
> advantages as well as costs. Array-like is the first of this kind. We
> aren't against such things, the issue Andreas raises is the researchy
> nature of doing anything you could call a type system for a language such
> as JS -- whether structural or nominal types -- or both -- are included.
>
>
>  I should also note that the Closure Compiler types system was based off
>> the ES4 proposal, if you want to see how things played out.
>>
>
> Did you include all the "like" non-type crazy?
>
>
>  One thing that I have seen specifically, is that supporting "non
>> nullable" types, and distinguishing between "undefined" and "null" in the
>> type signature creates a fair amount of busy work ("type casts" to remove
>> nullability) for larger projects.
>>
>
> Yes, it's like const. You have to rule out null at an API boundary or
> other chokepoint, and then go non-null in the "kernel". C and C++
> programmers do this by hand (references in C++ only help so much -- and
> they give no runtime safety).
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120925/a4980987/attachment-0001.html>


More information about the es-discuss mailing list