On 26.12.2010 17:37, Lasse Reichstein wrote:
On Sun, 26 Dec 2010 08:55:33 +0100, Juriy Zaytsev <kan...@gmail.com>
wrote:
It makes sense to differentiate between "mutable [[Prototype]]" and
__proto__ — as one of its implementations.
It also makes sense to differentiate between real mutable prototype and
initially configurable prototype.
Yep, true. I had an experiment when I wanted to replace default
`Array.prototype` to handle negative array indicies and at the same time
to create arrays via literals. Unfortunately (or fortunately -- it
depends) it's not configurable, so I made an own constructor.
The examples where settable prototype makes sense have generally been of
putting a custom prototype on a Function, Array, or other object that
can't
be created using Object.create. If there were Function.create,
Array.create,
etc., would there be a need for a mutable prototype at all?
In a "well typed" program, my guess is no.
It already seems to me too. Also taking into account the ability to
modify the code dynamically (via console or even via address line) it's
bad for security. However, the client code cannot be trusted anyway.
__proto__ way of getting/setting [[Prototype]] is awkward, which is
why something like `Object.setPrototype` could be a better choice. So
I would gladly replace __proto__ w.
Object.setPrototype, since we don't lose much there; but gain
consistency
and robustness.
I agree. Having "magic" properties on all objects is an annoyance.
Ditto for __setter__,
__getter__, etc., in the engines that have those.
As was mentioned, it was the time when unstratified meta-programming was
modern. It can be still modern and useful if will avoid some issues,
such as parsing JSON which contains `__proto__` or similar.
By the way, Lua which I noticed has also stratified setting of the
prototype (via setting a `meta-table`), but not directly on the object
(as could seemed in my previous message when I mentioned Lua in this
respect of setting a prototype).
As far as mutable [[Prototype]] in general...
I can think of 2 somewhat useful examples. I'm not taking cases that are
already solved by ES5 — like creating "clean" hashtable — into
consideration.
... where both only need to modify the prototype chain on object
creation.
Either an ability to change object's class at creation (in case of
sub-classing Array).
Dmitry.
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
