Harmony object literals
On Jun 6, 2011, at 2:31 AM, Kam Kasravi wrote:
In the object literals proposal the following 2 examples are given below: var enhancedArrayProto = Array.prototype <| { do (func) {return this.foreach(func)}, search (key {return this.indexOf(key) >= 0} }; var myArray = enhancedArrayProto <| [0,1,2,3,4,5];
- I believe search is missing a ')'
yes
- The first example is adding another prototype to Array.prototype, eg Array.prototype.prototype that contains do and search. Since this appends to the proto chain is it correct to say it's not possible to override methods using this operator? That is it's effect should only be additive?
It is creating a new object whose [[Prototype]] is Array.prototype. If this new object is used as a prototype it will provide all of the inherited Array.prototype methods plus do and search. The new object could over-ride properties defined by Array.prototype but in this example it does not.
- Since the <| operator accepts an ObjectLiteral would it be extended to include classes?
Yet to be determined. Whether it is useful/meaningful will depends upon how constructor inheritance is defined via the class declaration.
var enhancedArrayProto = Array.prototype <| class { public do (func) {return this.foreach(func)} public search (key) {return this.indexOf(key) >= 0} }; 4. I'm not quite clear on what the myArray example does, is it adding a new prototype that provides initialization of some kind?
It is just creating a new array object whose immediate [[Prototype]] is enhancedArrayProto. The new object has all all of the special array functionality.
I see, the object's prototype is to the left of <| and the actual object is to the right. I guess that was made clear in the proposal though I suspect others will invert the relationship since javascript programmers are used to defining the prototype after defining the object. The <| operator seems like you're piping something into a target rather than the other way around, you know like the shell < operator. Thanks for the clarifications.
On Jun 6, 2011, at 9:38 AM, Kam Kasravi wrote:
I see, the object's prototype is to the left of <| and the actual object is to the right. I guess that was made clear in the proposal though I suspect others will invert the relationship since javascript programmers are used to defining the prototype after defining the object.
"... after defining the constructor", you mean? Because with object initialisers that preset proto, programmers definitely create prototype before delegating object.
The <| operator seems like you're piping something into a target rather than the other way around, you know like the shell < operator. Thanks for the clarifications.
The exact syntax is still being fine-tuned and perhaps even debated.
On Jun 6, 2011, at 9:48 AM, Brendan Eich <brendan at mozilla.com> wrote:
On Jun 6, 2011, at 9:38 AM, Kam Kasravi wrote:
I see, the object's prototype is to the left of <| and the actual object is to the right. I guess that was made clear in the proposal though I suspect others will invert the relationship since javascript programmers are used to defining the prototype after defining the object.
"... after defining the constructor", you mean? Because with object initialisers that preset proto, programmers definitely create prototype before delegating object.
Yes agreed, though most frameworks I've used do not muck with proto in a declarative way, rather they do the more imperative style of FunctionDeclaration followed by the prototype. This is because most only ever see proto referenced on Mozilla pages, do not know the extent of cross browser support for proto, and probably figured that var o = { proto : myProto, a:0, b: function () {} } was equivalent to var o = { prototype : myProto, a:0, b: function () {} } Tried it and were burned by it.
On Jun 6, 2011, at 9:38 AM, Kam Kasravi wrote:
I see, the object's prototype is to the left of <| and the actual object is to the right. I guess that was made clear in the proposal though I suspect others will invert the relationship since javascript programmers are used to defining the prototype after defining the object. The <| operator seems like you're piping something into a target rather than the other way around, you know like the shell < operator. Thanks for the clarifications.
The primary reason is that the actual object must be a literal form and if the order was reversed the <| (or perhaps |>) and prototype value would be visually lost at the end of a long literal. It's too important to come at the end.
var myObject = { //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... //a page of property definitions... } |> myProto;
Yes, I did read the rational and see why you put it first, though the cleanest IMHO is var o = { prototype : myProto, a:0, b: function () {} } Or perhaps
var o = { prototype = myProto, a:0, b: function () {} } Though I imagine the grammar impact for ObjectLiteral and ArrayLiteral for the latter would be onerous.
On Jun 6, 2011, at 11:04 AM, Kam Kasravi wrote:
Yes, I did read the rational and see why you put it first, though the cleanest IMHO is var o = { prototype : myProto, a:0, b: function () {} }
"prototype" is a valid property name that does not correspond to the [[Prototype]] of the the object.
Plus variants of this form do not work for specifying the [[Prototype]] of function or RegExp literals.
In the object literals proposal the following 2 examples are given below: var enhancedArrayProto = Array.prototype <| { do (func) {return this.foreach(func)}, search (key {return this.indexOf(key) >= 0} }; var myArray = enhancedArrayProto <| [0,1,2,3,4,5];