Re: Why are non-method properties in a prototype an anti-pattern?
You are thinking in constructors ... I think in `Object.create(fromObject)` where there's no initialization and defaults are more than welcome. There is no reason to assign all possible defaults per each instance creation ... it's costy so why would you ? I prefer assign/overwrite properties when needed, not because the language requires me doing it, you know what I mean :-) On Wed, Nov 7, 2012 at 9:17 AM, Axel Rauschmayer a...@rauschma.de wrote: In theory, one can use prototype properties to provide default values for instance properties. In practice, that is not often useful, because the constructor normally creates all instance properties right away, assigning default values where necessary. And, with default parameter values in ES6 that is even easier to do. As mentioned by Andrea in another thread, another argument against non-method prototype properties is that they prevent you from freezing the prototype (because that would make assigning to instance properties impossible). Any other reasons for why they are discouraged? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
Le 07/11/2012 18:17, Axel Rauschmayer a écrit : In theory, one can use prototype properties to provide default values for instance properties. In practice, that is not often useful, because the constructor normally creates all instance properties right away, assigning default values where necessary. And, with default parameter values in ES6 that is even easier to do. As mentioned by Andrea in another thread, another argument against non-method prototype properties is that they prevent you from freezing the prototype (because that would make assigning to instance properties impossible). inherited properties can be accessors. That's how WebIDL works. I have no opinion as to whether inherited data properties are a good or bad idea, though. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
Any other reasons for why they are discouraged?
This footgun:
function MyClass() {
this.value = 1; // OK
this.list.push(0); // Modifying the list for every instance -
probably not intended.
}
MyClass.prototype.value = 0;
MyClass.prototype.list = [];
- Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
On Wed, Nov 7, 2012 at 12:27 PM, Kevin Smith khs4...@gmail.com wrote:
Any other reasons for why they are discouraged?
This footgun:
function MyClass() {
this.value = 1; // OK
this.list.push(0); // Modifying the list for every instance -
probably not intended.
}
MyClass.prototype.value = 0;
MyClass.prototype.list = [];
+1 beat me to it.
- Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
Nice one!
On Nov 7, 2012, at 18:27 , Kevin Smith khs4...@gmail.com wrote:
Any other reasons for why they are discouraged?
This footgun:
function MyClass() {
this.value = 1; // OK
this.list.push(0); // Modifying the list for every instance - probably
not intended.
}
MyClass.prototype.value = 0;
MyClass.prototype.list = [];
- Kevin
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
On Wed, Nov 7, 2012 at 9:17 AM, Axel Rauschmayer a...@rauschma.de wrote: In theory, one can use prototype properties to provide default values for instance properties. In practice, that is not often useful, because the constructor normally creates all instance properties right away, assigning default values where necessary. And, with default parameter values in ES6 that is even easier to do. As mentioned by Andrea in another thread, another argument against non-method prototype properties is that they prevent you from freezing the prototype (because that would make assigning to instance properties impossible). This is due to the override mistake http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake and affects methods as well as non-methods, since both are often overridden by assignment. The unpleasant conclusion is that, since the committee failed to agree to fix this mistake, the unfortunate generalization of your conclusion is one of * Method and non-method properties in a prototype are an anti-pattern, which becomes using prototypal inheritance is JS is an anti-pattern. * Overriding by assignment is an anti-pattern, in which case, both method and non-method inherited properties are fine. In any case, note that the same kludge http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#369 fixes both. Any other reasons for why they are discouraged? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
that's a feature ... and if you do that either you know what you are doing
or you need to know what you are doing.
Shared objects are powerful, not a problem .. not the problem here, imho
On Wed, Nov 7, 2012 at 9:27 AM, Kevin Smith khs4...@gmail.com wrote:
Any other reasons for why they are discouraged?
This footgun:
function MyClass() {
this.value = 1; // OK
this.list.push(0); // Modifying the list for every instance -
probably not intended.
}
MyClass.prototype.value = 0;
MyClass.prototype.list = [];
- Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
On Wed, Nov 7, 2012 at 9:17 AM, Axel Rauschmayer a...@rauschma.de wrote: In theory, one can use prototype properties to provide default values for instance properties. In practice instances are free to write on these values in addition to using them as defaults. Then suddenly the 'default' is changed for other instances. It is then you realize that the theory is not a very good one. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
same would be for data methods On Wed, Nov 7, 2012 at 9:52 AM, John J Barton johnjbar...@johnjbarton.comwrote: On Wed, Nov 7, 2012 at 9:17 AM, Axel Rauschmayer a...@rauschma.de wrote: In theory, one can use prototype properties to provide default values for instance properties. In practice instances are free to write on these values in addition to using them as defaults. Then suddenly the 'default' is changed for other instances. It is then you realize that the theory is not a very good one. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
also, properties can be defined as getters and setters so that you might want to share them in the same scope/context the rest of the prototype is defined and not later on inside the constructor. Yes, there are work around for this but again, if that Object.freeze problem is solved, there is no reason to avoid properties in the prototype, imho On Wed, Nov 7, 2012 at 10:02 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: same would be for data methods On Wed, Nov 7, 2012 at 9:52 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Nov 7, 2012 at 9:17 AM, Axel Rauschmayer a...@rauschma.dewrote: In theory, one can use prototype properties to provide default values for instance properties. In practice instances are free to write on these values in addition to using them as defaults. Then suddenly the 'default' is changed for other instances. It is then you realize that the theory is not a very good one. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are non-method properties in a prototype an anti-pattern?
On Wed, Nov 7, 2012 at 6:27 PM, Kevin Smith khs4...@gmail.com wrote:
This footgun:
function MyClass() {
this.value = 1; // OK
this.list.push(0); // Modifying the list for every instance -
probably not intended.
}
MyClass.prototype.value = 0;
MyClass.prototype.list = [];
Thing is, this is not initialization. That would be setting it to null.
I do realize what you mean, and for new people it might look the same,
but it just is not.
I always explicitly declare all instance properties (method but also
non-method) in the prototype, never in the constructor. More often
than not, they won't even occur in the constructor if they're not used
there (yes, I know about jit class stuff, but in most apps it really
doesn't matter). Declaring them on the proto makes it easy to look-up
what instance properties an object/class might have and is a good
point for documentation (imo, better than doing so inside the
constructor).
And in that regard; not being able to specify them in a class
definition is an error (but I have no idea about the current state of
the proposal, so feel free to ignore this).
I know many people (here) don't use, or even are against, initializing
all instance properties on proto, but I still stand by it. Just my two
cents.
- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
