Optional argument types

[John Lenz]

that should have been "unrelated structures can look the same".  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.

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.  Although, the provide some level of
comfort for small projects (where everything is in your control).



On Tue, Sep 25, 2012 at 8:50 AM, John Lenz <concavelenz at gmail.com> wrote:

> As a point of reference the Closure Compiler doesn't choose but supports
> both record types (structural) and "instanceof" (nominal) types in the type
> system.  The big down side of nominal types in JS is there is no way to
> express interfaces (the Closure Compiler type system supports them with
> annotations), so unless a means is added for expressing interfaces in some
> form (mixins, traits, or what have you) that can respond to an
> "instanceof",  nominal types are simply not expressive enough.
>
> The problem with structural types in a dynamic language is that the checks
> are potentially costly.  I'm not sure this is true for today's VMs or not
> (are the hidden classes they use sufficient to make these checks
> efficient?) but if nothing else runtime support for them will require
> additional bits.    Structural types are also intentional sloppy, related
> types can look the same.   For example, the structural question of "do you
> have an 'id' field" doesn't answer for the intended use of that field.
> Of course, being able to ask the question in an efficient manner for
> complex structures would be a huge win over what needs to happen now if you
> want to check for structural compatibility.
>
> For writing tests, I've always been in favor of object that override type
> checks regardless of whether they are structural or nominal.  I'm not sure
> what this means for structural checks.
>
>
>
>
>
>
> On Tue, Sep 25, 2012 at 6:31 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> That's a hell of a question ... shapes speaking I'd say structural, since
>> AFAIK shapes are those boosted up more, isn't it?
>>
>> That would solve String VS string and Array VS Arguments which is, I
>> believe, kinda desired.
>>
>> Which one would you chose ?
>>
>> On Tue, Sep 25, 2012 at 12:04 PM, Alex Russell <slightlyoff at google.com>wrote:
>>
>>> Perhaps, but it's easy to be too naive about what VMs do (and don't do).
>>> Best to design for semantics with performance in mind, not the other way
>>> around.
>>>
>>> In any case, would you be looking for nominal or structural type tests
>>> here?
>>>
>>> On Sep 25, 2012, at 11:44 AM, Andrea Giammarchi <
>>> andrea.giammarchi at gmail.com> wrote:
>>>
>>> ... or the ability to boost up a lot JIT and performances ... but I
>>> agree on the non trivial, rich in ugly JS corner cases too, e.g. string as
>>> primitive VS String as instanceof
>>>
>>> On Tue, Sep 25, 2012 at 10:23 AM, Andreas Rossberg <rossberg at google.com>wrote:
>>>
>>>> On 24 September 2012 20:53, Dmitry Soshnikov <
>>>> dmitry.soshnikov at gmail.com> wrote:
>>>> > I think it's just the matter of the need. If these optional argument
>>>> types
>>>> > are very needed by devs, then it's probably not a big deal to add
>>>> them to
>>>> > the standard -- after all it's still in the draft, not published
>>>> (it's just
>>>> > a small section on generating the prologue, isn't it?).
>>>>
>>>> It actually is a very big deal. Getting such a feature right is highly
>>>> non-trivial, with lots of ugly JS corner cases to worry about. Let
>>>> alone a good runtime cost model.
>>>>
>>>> /Andreas
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120925/2bccbf21/attachment.html>