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?
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
Object.prototype.
I.e. we can use "obj.getPrototype() freely here..." -- only inside
this
object (in this case -- inside this function)?
Yes.
And outside of this
object "obj.getPrototype()" can mean completely different thing --
with
"string" or "name" key, right?
Right.
And if already was declared the same
"name"/"string" property, it isn't collide because our local
"getPrototype"
name has other identity, yeah?
Yes.
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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
