"Syntax for Efficient Traits" is now ready for discussion
Tom Van Cutsem
tomvc.be at gmail.com
Thu Oct 7 11:21:12 PDT 2010
Hi MarkM and Tom, possibly it will be interesting to you:
> http://gist.github.com/613924 -- a delegation based mixins implemented
> using Harmony proxies.
> - working in two modes: traits (naming conflict predicting at early
> stage), or simple linearization (mixins mode, there is no warning about
> naming conflicts);
> - "in" operator is working on object (e.g. *"foo" in bar* is *true* if
> either *bar* has own property "foo", or any of mixed objects have the
> property (including consideration of their prototype and mixin chains), or
> if the property is found in the prototype chain of the *bar*).
> Cons: possible overhead on reading / or testing for "in". Should be avoided
> at lower level implementation.
> TODO: syntactic sugar (possibly for CoffeeScript).
It's an interesting experiment. On first sight, your inheritance mechanism
looks very similar to Ruby's modules. Although one big difference is that in
your experiment, your mixins can also have their own prototype chain (IIRC
in Ruby, modules can't inherit). I think that may be a bit too flexible,
leading to even more complex lookups than is the case with multiple
inheritance. If you would ignore the prototype of the mixins, you end up
with something called "comb inheritance" (at each level, check the object
and the mixins horizontally, if not found go up one level on the prototype
chain and try again) which is a bit more tractable for programmers to deal
with, I think.
Your experiment does show that it's possible to combine conflict detection +
delegation to some extend. However, I wouldn't call your conflict detection
mode "trait mode". First: the system is not conflict-proof: if some code
adds a property to a mixin object or to the target object at a later point
in time, potential conflicts will go undetected. Second, even in "trait
mode" the ordering of the mixins matters (trait composition is commutative,
ordering is not important, at any level of composition). Third, there seems
to be no obvious way to resolve/avoid a signaled conflict (traits have
aliasing or overriding to deal with this).
> P.S.: it's good to have *noopHandler* for proxies as a built-in function,
> it's a useful sugar (possibly even to make it as a default handler (if some
> handler's properties are not specified), though it may be unnecessary
Yes, I agree! We've talked about this in the past but haven't yet settled on
a standard API. Perhaps we should.
I think Proxy.noopHandler(target) may be a bit obscure. Other suggestions:
> P.S.: proxies are nice ;)
Thanks! Keep on experimenting :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss