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.
Features:
- 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 ;)
Dmitry.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
