Approach of new Object methods in ES5

Brendan Eich brendan at
Sun Apr 18 06:01:52 PDT 2010

On Apr 18, 2010, at 7:13 AM, Dmitry A. Soshnikov wrote:

> This desugared view with enclosing anonymous function means that
> "getPrototype" name is available only in scope of of this function and
> when this scope ends, "getPrototype" name will be GC'ed (and related
> object too -- {value: ...})

That object may be GC'ed earlier, it's just a descriptor used to  
define the prototype property.

> and "Object.prototype" again won't have
> "getPrototype" name outside, right?


> (Although, it's a bit strange, as it shouldn't be GC'ed as there is
> object related with this "name" object and vice-versa -- the "name" is
> still bound to this object {value: ...}. But, I don't know exactly
> about implementation).

See ES5 -- Object.defineProperty(Object.prototype, getPrototype,  
{value: ...}) does not retain a reference to the {value: ...} object  
after it returns. It merely consults it to see how to define the  
property named by (in this case) the getPrototype Name object in  

> I.e. we can use "obj.getPrototype() freely here..." -- only inside  
> this
> object (in this case -- inside this function)?


> And outside of this
> object "obj.getPrototype()" can mean completely different thing --  
> with
> "string" or "name" key, right?


> And if already was declared the same
> "name"/"string" property, it isn't collide because our local  
> "getPrototype"
> name has other identity, yeah?


> But is there much sense in providing this "getPrototype" name for
> "Object.prototype" just inside our local library to make it convenient
> just for ourselvels. In this case we can provide some simple function.

We could. But let's not go in circles: the premise is that  
Prototype.js's style of extending built-in constructor's prototypes  
(except for Object.prototype) is winning in terms of programmer  
productivity, both producing (keystrokes) and consuming (readability).

I just confirmed that Prototype people do not plan to stop extending  
built-in prototypes including Array, here at JSConf 2010. They are  
moving away from extending DOM prototypes, I'm told, but not the  
standard ones.

Anyway, this is more of a thought experiment about how to extend  
standard prototypes without collisions. Recall the objection from  
yourself and Dean Edwards to ES5's Object.keys, etc. At least Dean  
averred that he preferred not only shorter names like keys to  
getOwnPropertyNames, etc., but also prototype-based "instance methods"  
to the Object-based "static methods".

> But the main goal is to achieve the most convenient and elegant code
> reuse stylistic via placing this "getPrototype" directly into
> "Object.prototype" and make it available for /all users/ outside the
> library but not only for us inside the library.

If you want to add a string-named property to Object.prototype, you  
can do it with ES5's Object.defineProperty -- no need for Name  
objects. It still might break some object-detecting code that checks  
for that string-equated name, though (again the premise for hauling in  
Name objects to the discussion).

>> You have to keep your hands on the getPrototypeName const in order to
>> use it as an identifier in obj.getPrototype(), of course.
> Unclear; you mean I should first define const "getPrototype" and then
> I can use it as "obj.getPrototype()"?
> I.e.:
> const getPrototype;
> private getPrototype;
> ?
> Or I didn't understand correctly?

In the names proposal, just 'private getPrototype;' would be enough.

>> So the module pattern (or real modules or lexical scope, also coming
>> in Harmony in some form) is as important as the Names proposal.
> By the way, is there any ability to test some Harmony implementation
> already? Maybe some part of it which currently is being implemented?

Some, so far mainly harmony:proxies for SpiderMonkey, see this bug.

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

More information about the es-discuss mailing list