I think the fact you had to write two solutions where one attach to the
object the listener and another one needs a double arrow (rainbow) already
shows we have a hole in the language once covered by arguments.callee.
just to make sure we are not misunderstanding each other: I wrote
two solutions because the initial examples I saw only needed recursion
for anonymous functions, a problem which has standard solutions.
Your example had more stringent conditions in that the self-reference
also needed to preserve the identity of the anonymous function (for
de-registering listeners). The modified solution should serve both
examples as a replacement for arguments.callee (I think).
The only example it hasn't solved is the one with concise methods,
where the syntactic sugar keeps us from wrapping the function at
the definition site. Since wrapping functions at call-sites is awkward,
I suggested alternatives.
The more you write examples, the more you convince me we are
missing callee ;-)
Again, this is jut my opinion. There are ways to work around this,
it just feels wrong we lost the callee feature.
We just got rid of the 'this' workarounds, and it cost us a whole
second set of function expressions. We still haven't solved all of
the 'super' issues. Do you really want to multiply these issues by
introducing yet more implicitly scoped meta-level references?
Everyone is welcome to their opinions, but I'd rather avoid taking
the bait of minor conveniences, only to run into solid issues later.
To me, this looks like one of the cases where language designers
have to be more careful than language users in what they wish for.
My reference to Lisp was only half kidding: Lisp was born from
meta-level concepts, so everything was possible, programs talking
about and rewriting themselves were cool and seemed to offer
easy solutions to everything; later languages like Scheme, ML,
and Haskell have largely followed a path of trying to achieve
comparable (or better) expressiveness while reducing the
reliance on meta-level (and other too powerful) features.
Their language designers had to work hard to get there while
avoiding the seemingly simple path, but the result is that it is
much easier to reason about and refactor a Haskell program
than the equivalent Lisp program (which also makes optimization
easier, which makes seemingly complex features cheap to use).
Ok, getting off my soapbox now, sorry for the interruption:-)
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
