On Apr 3, 2008, at 8:23 AM, Kris Zyp wrote: >>> the moment, but I assume you can't do replace a method on a user >>> class >>> with >>> another ad-hoc function. >> >> Absolutely not with fixtures, > > I was thinking about this, is there any reason why you can't replace a > class's method with another method or install a method on an > instance object > that overrides the class's method, assuming that the method signature > remains the same, the body has correct typing use of |this|, and > the class > is non-final? This seems to have the same integrity as method > overriding in > subclasses. Being able to do this (and possibly dynamically adding > methods > to classes) would bring the level of dynamicism that Mark had > suggested with > his ES4 sugar proposal (being able to create classes on the fly)
Mark's sketch did not allow method replacement, however. AOP is not the root password to mutation barriers added to enforce integrity properties. It is not even formally sound, last I looked. And its main use-case is logging or other such post-hoc, cross- cutting instrumentation. If the universe of objects already contains some (like certain built-in objects including DOM nodes in most browsers) whose methods cannot be replaced, which must therefore be wrapped for AOP-style hacking, then why wouldn't we want classes to behave as proposed in ES4? Wrappers will be required; they already are for security in browsers I've studied (or they are coming soon, at any rate). Any code not insisting on a nominal type relation, i.e., using * (implicitly as in untyped code today, or explicitly), or a like test, or a structural subtype test, could let wrappers through. Just as DOM wrappers can satisfy hand-coded "shape tests" in today's untyped libraries that use AOP. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
