David Bruant david.bruant at
Sat Sep 24 15:05:31 PDT 2011

Le 24/09/2011 23:37, Jake Verbaten a écrit :
> On Sat, Sep 24, 2011 at 5:03 PM, David Bruant <david.bruant at
> <mailto:david.bruant at>> wrote:
>     I'm a big fan of the proto operator proposal, however, as raised
>     previously this operator relies on the object being created to have an
>     intialisation syntax. This prevents, for instance, Date objects to
>     have
>     a custom prototype with this method. I am not very familiar with
>     it yet,
>     but I think that if they ever came to life, ParallelArrays [2] would
>     suffer from the same problem.
>     By the way, could someone add this concern as a note ("open issue" or
>     "limitation" or something like this) in the proto operator page,
>     please?
> I don't understand the limitation for `Date`. 
> var d = proto <| new Date();
Based on the proposed grammar (see
), it would fail since "new Date()" isn't a ProtoLiteral.
JavaScript has a very dynamic nature:
this.Date = function(){console.log("Date")};
console.log(new Date()); // Logs 'Date' and create a new object as in {};
"Date" is not an element of syntax, it's something with a value decided
at runtime. When you call "new Date()", you can't know in advance what
is going to happen, so, you have to call it, but when it's called, the
object is here already with a given prototype, so you can't change it.

It's different when you have syntax:
var o = {};
var a2 = o <| [1, 2, 3];
Here, the array syntax literal guarantees (since ES5, not in ES3!) that
a native array is going to be built. Same goes for "function(){}" or any
object created with reliable syntax, so the parser can both safely build
the object and assign the chosen prototype.

That's my interpretation though and i'd be happy to hear from others.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list