Using Object Literals as Classes

Rick Waldron waldron.rick at gmail.com
Fri Mar 16 16:49:31 PDT 2012



On Mar 16, 2012, at 7:37 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:

> From: Rick Waldron [mailto:waldron.rick at gmail.com] 
> 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 <domenic at domenicdenicola.com> wrote:
>  
>  
>  
> From: Rick Waldron [mailto:waldron.rick at gmail.com] 
> 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 <domenic at domenicdenicola.com> wrote:
>  
> On Mar 16, 2012, at 18:12, "Rick Waldron" <waldron.rick at gmail.com> wrote:
> 
>  
> 
> On Fri, Mar 16, 2012 at 6:04 PM, David Bruant <bruant.d at gmail.com> wrote:
> Le 16/03/2012 23:00, Rick Waldron a écrit :
> On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola <domenic at domenicdenicola.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120316/1760e768/attachment.html>


More information about the es-discuss mailing list