Agreed there are use-cases for second-class methods, according to style and taste.
The impetus for __noSuchMethod__ when I implemented it in 2003 was to support the Smalltalk-based TIBET framework of Bill Edney and Scott Shattuck. They religiously use a Smalltalk style of JS so do not feel any second-class pain. Other styles of JS would definitely feel pain. One size does not fit all. This is why rejecting an invoke trap is not a matter of black and white, IMHO -- it's simply a desire to reduce complexity and see how the result can be used by a library (a standard one, even) to implement something like __noSuchMethod__. /be ----- Original Message ----- From: "Dmitry Soshnikov" <[email protected]> To: "es-discuss" <[email protected]> Sent: Thursday, December 15, 2011 5:48:37 AM Subject: noSuchMethod: "funargs" + "invoke-only-phantoms" Hi, Here is the analysis of current "noSuchMethod" situation implemented via proxies. I summarized that never-ending thread from 2010 ( https://mail.mozilla.org/pipermail/es-discuss/2010-October/011929.html ), since guys in JS community started to ask why proxies don't support noSuchMethod. It's written as a small article in a view of JS-code: https://gist.github.com/1481018 Is there something to add? To change probably in the current Tom's proposal? Etc. P.S.: while I was writing the article, I started more to agree on importance of the "extracted funargs" in this case, however the "invoke-only-phantom" methods still and also (as it turns out) are needed to users and required by them. Cheers, Dmitry. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
