Minimalist (why) classes ?
John J Barton
johnjbarton at johnjbarton.com
Sun Nov 13 11:09:19 PST 2011
On Sun, Nov 13, 2011 at 7:42 AM, Rick Waldron <waldron.rick at gmail.com> wrote:
> On Nov 13, 2011, at 5:08 AM, Jake Verbaten <raynos2 at gmail.com> wrote:
>> Neither of them are fit for standardization. Selfish and Prototype are
>> both incapable of correctly "deep copying" arrays or objects,
> Why does it matter that they don't deep copy? Deep copying is a difficult
> problem that needs to be standardized separately.
> It matters because I don't want data pollution across "instances". It's not
> a hard problem at all, jQuery.extend() has had deep copy for years.
Just a couple of observations:
1) There are two different issues here: flatten vs retain
[[Prototype]] links and shallow vs deep copy.
2) I think the choice should be different for methods and data.
The first order effect of inheritance is to re-use methods; for this
purpose shallow copies and re-use by [[Prototype]] links works well.
However, if you adopt shallow copies or re-use by [[Prototype]] links,
the non-method data is copied by reference, causing write onto derived
objects to write onto ancestor object values. This is only rarely the
In Gonzala's selfish and in his gist, I believe the implicit
assumption is that developers should adopt a pattern of use: "ancestor
class" objects will have only function properties. The |initialize|
method will define data properties. In this way the shallow copy and
the use of [[Prototype]] links works for the methods and the data is
chained through calls to ancestor initialize(). I think this is also
implicit in Object.create(): LHS object is expected to be a pile of
This makes a lot of sense and it meshes well with class-thinking. What
it says is: adopt a different strategy for methods and for data. For
methods, retain the [[Prototype]] links; for data, flatten. The
first-order effect is the same as old PrototypeJS solution but the
second order effect, data in [[Prototype]] links vs data on the
object, is different.
No, I do not have a concrete proposal. But it seems to me that
Gonzala's gist extend() should attach the data properties to the
instance not the type. It only matters when the inputs have data
properties and in that case you probably don't want them on the
[[Prototype]] linked object.
More information about the es-discuss