On Mar 16, 2012, at 7:37 PM, Domenic Denicola <[email protected]> wrote:
> 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]> > wrote: > > > > 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]> wrote: > > On Mar 16, 2012, at 18:12, "Rick Waldron" <[email protected]> wrote: > > > > On Fri, Mar 16, 2012 at 6:04 PM, David Bruant <[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]> 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` Which can be avoided with .bind(this), today. > 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
