three small proposals: the bikeshed cometh!

Garrett Smith dhtmlkitchen at
Thu Apr 29 02:17:50 PDT 2010

On Thu, Apr 29, 2010 at 12:25 AM, Alex Russell <alex at> wrote:
> Some small, pre-colored panels for the shed. Given that these are mostly
> matters of syntax and not semantics, please believe me when I suggest that
> the warts discussed herein present sharp edges that should be rounded off by
> the committee -- not because they're interesting in any way but because the
> primary users of the language are shipping (bad) fixes around the network
> billions of times a day. Such rank inefficiency needs sunset date.
> Summary of proposals:
> ---------------------
>  // 1.) Really generic generics
>  ArrSubtype = function() { };
>  ArrSubtype.prototype = Object.create(Array.prototype);
>  var nas = new ArrSubtype();
>  nas.push("howdy", "pardner");
>  nas.slice(0) instanceof Array; // currently true
>  nas.slice(0) instanceof ArrSubtype; // will be true after fix

The Array prototype methods are not going to change the return type.
Doing that would break any existing code that is trying to use array
generics and expecting the `this` value to be an array.

>  // 2.) Shorthand for "function", aka the "not lambda"
>  node.addEventListener("click", #(e){ e.preventDefault(); });
>  node.removeEventListener("click" obj!#(e){ ... }); // see #3

That would be possible so long as it does not conflict with existing syntax.

AFAIK, "#" is used in Spidermonkey for recursive object literal notation:


- however it would not seem to conflict here.


> Discussion:
> -----------
> 1.) Really generic generics
> Methods on Array.prototype that today return instances of Array should
> instead return instances of whatever subtype begat them. Assume that the DOM
> sucked less and that NodeList instances were subtypes of Array. In that
> case, we should be able to do something like:

If a thought about code cannot be explained using correct terminology,
then it is not very well understood by the person doing the

I inferred from your example that you meant "an object that has
Array.prototype in its prototype chain".

The use of nonstandard terminology to describe ECMAScript tends to
harbor misconceptions about the language.

On that, NodeList is not - and should not be - an Array. The two
concepts should be understood independently before attempting to use
them.  This very subject was just discussed on WHAT WG list. Did you
see it? Here is the last message:

Elsewhere: "whatwg] WebIDL and HTML5"

>  NodeList.prototype.parents = function() {
>    // should return a NodeList
>     return { return n.parentNode; });
>  }
>  document.querySelectorAll("p").slice(2).parents().filter(...);
> Today, the only way for subtypes to use these generics is to wrap or
> re-implement them. The functions that need to be fixed include:

No functions need to be included.


> 2.) Function shorthand


> Many functions, both in the DOM and in the library, accept functions as
> arguments. ES5 provides a bind() method that can ease the use of these
> functions when the passed method comes from an object. This is, however,
> inconvenient. E.g.:
>  node.addEventListener("click", obj.method.bind(obj, ...));
> Also, insufficient. Event listeners can't be detached when using
> Function.prototype.bind:

That is not true at all. I suggest reading the ES5 specifation that
before proceeding.



More information about the es-discuss mailing list