, hasOwnProperty(), and inheritance

Jake Verbaten raynos2 at
Tue Nov 8 12:19:02 PST 2011

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?

This seems like a right pain in the ass to debug/maintain?

On Nov 8, 2011 8:12 PM, "Luke Smith" <lsmith at> wrote:


 Brendan Eich <brendan at>
November 8, 2011 11:59 AM

> > On Nov 8, 2011, at 11:48 AM, Felipe Gasper wrote: > >> Actually, have
you ever seen a use case ...

I believe people decorate a class prototype directly because they always
have, and because defineProperties wasn't available for them to declare
prototype methods as not enumerable, not because they explicitly want class
proto methods to be enumerable.

Can you elaborate on "we should support abstracting over user-defined and
built-in functions"?

 All of the examples I’ve ever seen of the problems that ensue from iteration and prototypes stem from extending Object.prototype.
Why not, then, specifically address that problem rather than
preventing all iteration through inherited properties?

> > I think you're focusing too narrowly. I agree with Jake: make a copy
into a single object, and a...

Copying loses the benefit of shared defaults via prototype.  I would rather
see a method to flatten an object before enumeration than lose the
flexibility of shared state.


es-discuss mailing list
es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <>

More information about the es-discuss mailing list