On Sun, Aug 24, 2008 at 7:41 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > On Aug 24, 2008, at 7:36 PM, Peter Michaux wrote: > >> On Sun, Aug 24, 2008 at 6:05 PM, Brendan Eich <[EMAIL PROTECTED]> >> wrote: >>> On Aug 24, 2008, at 4:09 PM, Mark S. Miller wrote: >> >> [snip] >> >>> Others on this list should comment on class-private vs. instance- >>> private. >> >> If this is just a poll then I'm all for instance-private. >>
(order restored) > Polls are not so good, compared to reasons. Could you give your > rationale and talk about the trade-offs, in your experience? > I'm not Peter, but here are my observations: How to make a private variable? Option 1: "Fake Private" - uses _someVar, and even uses JSDocToolkit @private or @internal. Pros: Refactoring that introduces "private" instance variables won't require changing to "Power Constructor" or other closure-based approach. Cons: Fake. Example: http://developer.yahoo.com/yui/docs/menu.js.html _nCurrentMouseX: 0 is the default in Menu.prototype. In _onMouseOver, the value is set on the instance. It is as if the desire is to inherit the privateness, it is almost as if they wanted [[CanPut]]("_nCurrentMouseX") to be true only in the Menu code in that js file. Option 2: Closures. Wrap everything in a closure and have the "private" variables not accessible from the outside. This includes the Module Pattern, Power Constructor (Putting everything in the constructor), and Exporting Pattern approaches. Closure Pros: * Can use shortened lookup chains for "local" variables in the closure. * Can minify the "private" variables using a compressor. Closure Cons: * Private instance variables don't fit into the typical constructor-function-with-a-prototype idiom. Power Constructor cons: * Long constructor * increases the scope chain of each instance method, which then has reference to things it might not want or need (all variables remain in scope). Module Pattern cons: * increases the scope chain of each instance method, which then has reference to things it might not want or need (all variables remain in scope). * "private" variables are not easily distinguished from "local shortcut" variables. The Exporting Pattern is used to export some methods in a closure to properties of another object, keeping some "private" variables/functions. Exporting Pattern cons: * can lead to "God Object" or "Big Ball of Mud" * can be difficult to read/understand Garrett > /be > >> Peter >> _______________________________________________ >> 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 > _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
