From: Rick Waldron [mailto:[email protected]] Sent: Friday, March 16, 2012 18:40 To: Domenic Denicola Cc: David Bruant; es-discuss Subject: Re: Using Object Literals as Classes
On Fri, Mar 16, 2012 at 6:20 PM, Domenic Denicola <[email protected]<mailto:[email protected]>> wrote: On Mar 16, 2012, at 18:12, "Rick Waldron" <[email protected]<mailto:[email protected]>> wrote: On Fri, Mar 16, 2012 at 6:04 PM, David Bruant <[email protected]<mailto:[email protected]>> wrote: Le 16/03/2012 23:00, Rick Waldron a écrit : On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola <[email protected]<mailto:[email protected]>> wrote: Just to contribute to this... er... fun-thread... My team uses the closure pattern for our "classes" (i.e. no prototype methods at all), since we value encapsulation. I can't imagine we're alone. For my own curiosity, can you point me to some examples where you are strategically avoiding the use of the prototype pattern? When he needs actual encapsulation. Unfortunately, methods on prototype require to have properties that are public. If you avoid prototype methods, all your attributes and private methods can be shared by public method scopes. Sorry, I don't subscribe to this as an adequate argument against prototypes. jQuery has a whole lot of hidden, private functions and data - using an IIFE. Ultimately, the developer makes the decision to write well encapsulated code - prototype or closure pattern should have no bearing. Rick David That only works for singleton modules, not multi-instance classes. Multi-instance as in many instances created from a "class"? Every call to jQuery or its alias $ actually produces a new, unique object instance from a real constructor. The example you gave produces a constructor that wraps a handful of instance method definitions along with several function declarations - which I'm arguing could just as easily be outside of that function declaration, but inside of an IIFE. There are two issues here: 1) “Private methods” could be moved outside to the module level (IIFE level if you wish). This is true, but would necessitate passing the private state into these methods: `callListener` would need `options`, which then propagates to an extra parameter on `callListenersForSync` and `callListenersForAsync`. Obviously this problem multiplies as you add more private state to the object, eventually ending up passing around a “secrets” object containing all your private state, which is a bundle of joy to program against. </sarcasm> 2) “Public methods” cannot be moved outside to the prototype level. If instead of `that.publish = function () { ... }` inside the constructor, I had `Publisher.prototype.publish = function () { ... }` outside the constructor, then the function body could not access the “private instance variables” `normalListeners` and `oneTimeListeners`, or the constructor parameter `options`. The only way to allow a `Publisher.prototype.publish` method to access this per-instance state would be to un-encapsulate it, making it public so that they could be accessed as e.g. `this._normalListeners`. This is what I mean when I say I eschew the prototypal pattern in favor of the closure pattern. All of my methods are instance methods, because they need access to private, encapsulated state.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
