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._______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
