Standardizing __proto__

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Fri Mar 18 13:46:07 PDT 2011


JFTR, I remember the previous the same discussion(s) and mentioned 
earlier the thing similar to this `Object.subclass`, though, just with 
providing an ability to specify the [[Class]] for `Object.create`. E.g. 
for a unclassified inheritance:

let foo = Object.create(Array.prototype, "Array", {...});

and for classified as well:

// create new constructor, objects of which
// inherit from Array.prototype and are real
// arrays, additionally pass prototype properties
var Foo = Constructor.create({
// objects kind
class: "Array",
// an initializer
constructor: function Foo(args) {
this.push.apply(this, args);
},
// prototype properties (also may
// be added after "Foo" is created
prototype: {
size: {
get: function getSize() {
return this.length;
}
}
}
});
var foo = new Foo([1, 2, 3]);
console.log(foo.length); // 3
foo.push(4, 5, 6);
console.log(foo); // 1,2,3,4,5,6
console.log(foo.length); // 6
foo[7] = 8;
console.log(foo); // 1,2,3,4,5,6,,8
foo.length = 3;
console.log(foo); // 1,2,3

etc.

Other examples: 
https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/create.js

P.S.: yeah, mutable __proto__ is (was?) and interesting feature, but we 
tried to find its _real_ practical wide-spread application and couldn't. 
The same as we couldn't find the big practical rationale of the Python's 
__class__ from which __proto__ is borrowed. Yes, repeat, it's 
interesting from the _completely dynamic languages ideology_ (I like to 
show examples of first-class dynamic classes as oppose to second-class 
static classes), but if to start just analyze and try get again -- 
_real_ practical application, -- well, it's not so easy. Some internal 
lib hacks as mentioned by John cannot be considered as "practically 
widely spread". So the mutable __proto__ (no matter in which name and 
view) can be standardized only if (1) no security issues, (2.1) 
practically needed or (2.2) just "a cool stuff of dynamic languages" 
with unfortunately small practical application.

To avoid i-looping, Object.setPrototype(object, parent); is better than 
__proto__ of course.

Dmitry.

On 18.03.2011 22:36, David Bruant wrote:
> Le 18/03/2011 18:00, Oliver Hunt a écrit :
>> I kind of dislike the proliferation of .create methods.  It's seems inelegant.  What if we had (use __proto__ for semantic description)
>>
>> Object.subclass = function(constructor) {
>>      "use strict";
>>      function cons() {
>>          var result = constructor.apply(this, arguments);
>>          result.__proto__ = cons.prototype;
>>          return result;
>>      }
>>      cons.prototype = Object.create(constructor.prototype);
>>      return cons;
>> }
>
> Mike Shaver:
>> Andreas in IM that we hang it on the prototype chain, so that we get
>> it everywhere without repetitive specification.  How about:
>>
>> Function.prototype.createDelegatingTo = function (obj)
>> {
>>    var o = new this; // really new-with-apply(arguments) here
>>     o.__proto__ = obj;
>>     return o;
>> }
>
> One difference I see between Object.subclass and 
> Function.prototype.createDelegatingTo is that the latter does not 
> enforce anything on the prototype.
> --
> ( Array.createDelegatingTo({}) ) instanceof Array === false
>
> // while
>
> ( new Object.subclass(Array) ) instanceof Array === true
> --
>
> On the other hand, Function.prototype.createDelegatingTo is more 
> expressive and Object.subclass can be implemented from it.
> If methods such as Array.create are to be considered, this issue of 
> enforcing Array.prototype will have to be addressed. I have 
> personnally no strong conviction on one side or the other.
>
> David
>
>
> _______________________________________________
> 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/20110318/4cc93ac3/attachment.html>


More information about the es-discuss mailing list