Optional argument types

[Alex Russell]

On Wed, Sep 26, 2012 at 1:06 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> surely there's nothing to rush about, we survived already until now, no
> reason to go for a quick solution and mine was just a proposal based on the
> fact that most of the time contracts are based on primitives.
>
> However, If the problem is typeof null then ES should fix that first but
> AFAIK it came back to "object" at some point even under "use strict"
> directive and I never understood why ...
>

because it was a breaking change, a refactoring hazard, and having
different behavior for typeof inside and outside of strict mode has been
considered the likely source of endless "WTFJS" moments. It may be the case
that those arguments shouldn't have held sway and that the committee made a
mistake here, but every time we revisit the topic (and it happens more than
you'd expect), we end up at the same place (nearly no matter who is doing
the arguing on each side).

As a practical matter, the 1JS credo has removed much of the appetite for
divergent behavior that would have been needed to make this fix in. Modes
always bite back, and the question is "how hard". The currently dominant
answer is "as little as possible".


> primitives also means no wrappers allowed, which is a good practice,
> generally speaking.
>
> However, primitives does not mean "no Classes allowed" 'cause s:string and
> s:String could be both valid, and different, one typeof, one instanceof, as
> well as a:Array rather than just a:object where latter one would be
> permissive while first one will look for instanceof Array.
>
> The cross frame is nowadays a non-realworld-problem, I don't know any
> application that uses direct frames access rather than postMessage or JSONP
>


> ... in both cases instanceof Array should simply work ... but of course as
> long as it's possible to access other frames there could be a problem ...
> in that case, the function that would like to accept Array from any other
> window can specify a:object and do the [[Class]] check or use Array.isArray
> to ensure the type after ... create cross frames problems for a type-hint
> specification when the cross frame is disappeared from basically every
> library is a non-sense, imho ... who wants to allow such security
> problematic contract can use his own check, am I wrong?
>

I don't understand why it's problematic. We're talking about same-origin
windows. If there's something malicious on one, it's game over.


> As summary, string, number, boolean, undefined, function, null, object, as
> allowed types would cover already many needed cases, adding Array, Object,
> GenericScopedConstructor, global.name.spaced.Class on top of types can
> cover 100% of cases I know.
>
> Last but not least, if all this won't speed up a thing but actually will
> decrease JS performances, as Alex pointed out at some point, I would vote
> for **then don't** no matter what.
>

There's a tradeoff here: if this is cost that users are *already* paying
for when they write their APIs (either through instanceof/duck-type checks
or otherwise), a system provided way to say 'you must be this tall to ride'
may be perf-netural, and perhaps even positive to the extent that it
reduces boilerplate.

The counter argument is that making this a language feature is likely to
dramatically increase the use of such checks (and I agree with this). At
that point there's a debate about the marginal utility of each annotation,
either as check or as documentation. Dart is showing that you can use these
sorts of things a bumpers in development and simply elide them at runtime.
It's one extra position on the dial that wasn't well explored before. There
are others, and I think we should design with more of them on the table.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120926/e73d3650/attachment-0001.html>