From: Rick Waldron [mailto:[email protected]] Sent: Friday, March 16, 2012 19:28 To: Domenic Denicola Cc: David Bruant; es-discuss Subject: Re: Using Object Literals as Classes
On Mar 16, 2012, at 7:11 PM, Domenic Denicola <[email protected]<mailto:[email protected]>> wrote: From: Rick Waldron [mailto:[email protected]]<mailto:[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> There is more then one way to skin a goose... 2) “Public methods” cannot be moved outside to the prototype level. I should've used a period, or perhaps a whole new paragraph, because I never meant to imply that they could or should. 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`. Inside the IIFE, WeakMap (or shimmed equivalent) with instance as key, pointing to an object with all of those goodies stored in it. 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`. See WeakMap strategy above 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. I still say that this can all be accomplished with prototypes and IIFEs. I agree, it can all be done with WeakMaps or private names combined with modules and IIFEs, as I pointed out a few emails back and as Tab points out in another reply. But at that point (especially with WeakMaps, but also with unsugared private names) I am jumping through enough hoops that I’d rather just go the closure route. In my opinion, if ES6 delivers no sugar for private names, very few closure-pattern-using developers will jump through the necessary hoops to convert from closures to prototypes. (They’d also have to deal with losing the guaranteed `that = this` binding, but that’s another story.) That’s really the only point I wanted to make in this thread; I think we got sidetracked talking past each other about implementation patterns in current ES5/ES5-plus-WeakMaps environments.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
