Optional argument types

John Lenz concavelenz at gmail.com
Tue Sep 25 08:50:17 PDT 2012


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/4ec7ac7e/attachment-0001.html>


More information about the es-discuss mailing list