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 ste roids an d conflict risks! Thanks for you time & I'm looking forward to your feedback! -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
