I have realized this idea in a JS library: https://github.com/Gozala/method
Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Thursday, 2012-06-21 at 12:31 , Irakli Gozalishvili wrote: > 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/ > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
