private name methods ?

[Irakli Gozalishvili]

I get few comments on twitter regarding this:  

> So the idea is that a private name object is callable,
> and name(obj, ...rest) delegates to obj[name](...rest)?

Yeah thats is a primary idea:

name(object, …rest) => object[name](…rest)  

Although my hope is that `null` and `undefined` could also be supported in some way.
Note that with following will work only if `object` is from the same JS context (iframe):   

  Object.prototype[name] = function() { … }
  name(object)

Hopefully `name` implementation for `null` would enable it for objects from other contexts as well.


In addition I have proposed that `name` would just return property if it's not a function:

name(object, …rest) => typeof(object[name]) === 'function' ? object[name](…rest) : object[name]

Which pot pretty negative feedback:

>  It overlaps and precludes the case where you just want to get the function without calling.

As a matter of fact I outlined the primary case where this feature is very helpful in the gist:

Watchable.prototype[watchers] = function(target) {
  return target[watchers] = []
}

This enables lazy initialization of private properties that otherwise would have required second private
name. While I find this use case quite compelling I see drawbacks as well. Never the less I think that
even without the last feature callable private names are pretty compelling.



Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/


On Thursday, 2012-06-21 at 11:54 , Irakli Gozalishvili wrote:

> Hi,  
>  
> Some time ago I tried to get your intention about clojure protocols as I see them as better fit for JS and it's runtime than currently proposed classes. Although I can see that they may have implied too much new semantics. Recently I realized that private name objects can be used to do most of what protocols do with some boilerplate & performance penalties:
>  
> https://gist.github.com/2967124  
>  
> I was wondering if it's a good idea to adjust "private name objects" proposal, since IMO it solves some of the ergonomics related issues that would prevent it from taking off:
>  
> API for calling private named methods is awkward:  
> object[method](foo, bar)  
>  
> With private name methods it's natural:
> method(object, foo, bar)  
>  
>  
> API for accessing private names is ugly in comparison to normal properties:
> var data = object[secret]  
>  
> With private methods it can be more natural:
> var data = secret(object)
>  
>  
>  
>  
> Private methods can provide not only more natural API (that feels similar to one used today), but there is much more to it, private methods provide semantics very similar to clojure protocols (https://vimeo.com/11236603) that arguably enable interesting ways to do polymorphism (http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post) that IMO fits much better JS runtime than proposed classes. It is also fully harmonious with JS prototypical inheritance. It also solves issues inherent with diversity of community and libraries, as on may define protocol through the set of methods that can be independently implemented for set of libraries used. For example event dispatching protocol may be defined via on, off, emit private methods that later can be implemented without any conflict risks for DOM, jQuery, Backbone, etc... This will allowing one to use same set of privates methods regardless of which library data structure comes from. In a way monkey patching on steroids and conflict risks!
>  
>  
> Thanks for you time & I'm looking forward to your feedback!
> --
> Irakli Gozalishvili
> Web: http://www.jeditoolkit.com/
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120621/5cdc43b6/attachment.html>