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