On Mon, Dec 20, 2010 at 5:06 AM, Dmitry A. Soshnikov < dmitry.soshni...@gmail.com> wrote:
> On 20.12.2010 12:04, Peter van der Zee wrote: > [use cases for __proto__?] > Really, I can't remember some _very_ needed use-case of exactly changing > `__proto__` dynamically. > It makes sense to differentiate between "mutable [[Prototype]]" and __proto__ — as one of its implementations. __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. 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. 1. Callable instances (a weird thing, which I never understood much need for, but is theoretically interesting — http://gf3.ca/2010/12/16/executable-instances) 2. Proper sub-arrays (`Object.create(Array)` still doesn't give us true arrays in ES5; considering that semantics of instantiated object's [[Get]] and its [[Class]] values are different from those of array instances) If #2 is solved by other means (`Array.create` ?) then the need for mutable [[Prototype]] somewhat diminishes. Or does someone see any other applications for it? > > First, yes, I'm analyze it from the theoretical design viewpoint. > ECMAScript borrowed __proto__ from Python. It's called __class__ there -- > and it's also mutable. Though, I also can't remember cases when I was needed > to change the __class__ of an object dynamically at runtime (probably who > program Python more than me can provide some really useful cases), but such > an ability is (maybe to create some useful factories which may _classify_ > objects at runtime or sort of). > > The use cases related with ECMAScript I can imagine are: > > - an elegant way to form inheritance (the same way is used e.g. in Lua); > Just "another" way to form inheritance, right? Not necessarily more elegant :) > - creating the non-polluted hash-tables; > Could already be solved w. `Object.create(null, ...)` > - probably some ad-hoc small optimizations (with using for-in without > `hasOwnProperty` check); > Same solution as in previous. > - an ability to solve the problem "instance of a constructor check != > object of a needed class" (simpler, the ability to inject the needed > prototype to e.g. and array instance, http://bit.ly/hhLnRi); > Could you elaborate on this? [...] -- kangax -- 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
