for..in, hasOwnProperty(), and inheritance
felipe at felipegasper.com
Tue Nov 8 12:25:56 PST 2011
On 11/8/11 2:19 PM, Jake Verbaten wrote:
> Flexibility of shared state?
> Are you really corrupting the state of defaults at runtime? Do you
> really want changes to your default options to propogate to all objects
> extending the defaults?
It’s the same thing as redefining a method inherited from a prototype.
Why would you extend the default at all if you *don’t* want changes to
it to propagate to descendents? If you don’t want propagation, make a copy.
> This seems like a right pain in the ass to debug/maintain?
In some cases, maybe; in other cases, I think not.
It also can better model what’s going on: if the schema conceives of
multiple objects explicitly sharing the same default, then yes, you *do*
want descendents of the parent to stay in sync with the parent (unless
the descendents themselves have set values). That seems very intuitive
If you *want* a descendent to be independent of the parent, then don’t
make it a descendent; make it a copy.
FWIW, the YUI thing was pretty unintuitive to me and took me a while to
More information about the es-discuss