"Syntax for Efficient Traits" is now ready for discussion

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Sun Oct 3 12:44:03 PDT 2010

  On 16.09.2010 15:45, Dmitry A. Soshnikov wrote:
> On 15.09.2010 22:44, Tom Van Cutsem wrote:
>> Linearization is indeed a well-known approach to resolve the diamond, 
>> but it doesn't adequately 'solve' the problem from a software 
>> evolution point of view: small changes in one part of a large code 
>> base (i.e. changing the order of two 'include' or 'extends' 
>> statements) may end up impacting a totally different part of the code 
>> base - usually without warning.
> Yeah, but as I mentioned usually a user is aware about which modules 
> he includes and know which consequences (just a shadowing) he will 
> have in case of the same method names. In case if the user doesn't 
> know with which modules he deals, yeah, it's good to inform him about 
> that "be careful, the method of this trait shadows the previous one". 
> By the way, as I also mentioned, it's not a big problem to have it 
> (delegation based mixins with liniarization and naming conflicts 
> avoiding) even implementing on ES3 -- http://gist.github.com/575982. 
> There nothing prevents me to add the check at the beginning of the 
> "mixing" function, whether any method from "module" is (in the 
> inheritance + mixins chain) already in the "to" object. Though, this 
> implementation is mostly about academic curiosity and has some lacks, 
> however if to use new Proxy objects or even internal property 
> [[traits]] to handle mixed traits chain on [[Get]], then it's easy 
> possible to have the bundle "delegation based traits + naming 
> conflicts avoiding" mechanism. At least at mixing stage (to catch the 
> case when a new method is added to a trait, after the trait is already 
> mixed, it's needed to have overridden e.g. [[DefineOwnProperty]] for 
> traits).

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).

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 overhead).

P.S.[2]: proxies are nice ;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101003/163c849a/attachment.html>

More information about the es-discuss mailing list