Bill and Scott, I haven't discussed this with anybody else working on the ES3.1 specification so the following is just my opinion. However, it is the position I will take when we discuss the proposal, so here it is:
"Catch Alls" (this is the term that was used by the ES4 designers for this functionality) is something that should be investigated for ES-Harmony but is not something that should be considered for ES3.1. The primary reason for this conclusion is that we have set a hard deadline of the end of this years for completion of the ES3.1 specification and there would be significant work with unknown impacts required to incorporate the proposed "__noSuchMethod__" functionality into the specification. The immediate needs for the functionality does not appear to be great enough or broad enough to put the schedule at risk. Some of my specific issues with the proposal that I think need further work include: Why just methods? A common use of this sort of functionality is to "proxy" or otherwise emulate the public surface area of an object. This proposal doesn't do it. What about handling access to non-existent data properties (or getters/setters which amount to the same thing)? It seems like we should have a complete solution that works will all kinds of properties, not just "methods" calls. Another way to say the above, in ES3.0/3.1 specification terminology is: Is it invocation of missing "methods" that we want to handler on a per object basis or is it the reference error conditions in GetValue/PutValue (Section 8.7). Should the handler be expected to complete the operation (method call or data property get/set) or might it just return a replacement Reference value. (This would require reifying References up to the user program level, but it might be the right approach if we also want to enable emulation using ECMAScript code of host object methods that return Reference values). The full semantics of the feature needs to be expressed in the "formalism" of the ES3.1 specification (or latter the Harmony formalism). This will be necessary of inclusion in the specification but also for fully understanding the proposed semantics. Is looking for a methods named "__noSuchMethod__" (or any or name we decided upon) actually the best approach to exposing this function. A known problem with this approach is that it makes it difficult to proxy objects that themselves implement a "__noSuchMethod__" method. Other approach may or may not have similar problems but we should explore them to be sure one way or another. ES3.1 has started to try to more clearly distinguish meta operations upon objects (by making them function properties of Object) from normal application object operations. Defining a "noSuchMethod" handler feels like such a meta operations. Perhaps they should only be created via such a function). Do we understand the security implications? Do we understand possible performance implications particularly relating to various forms of caching that an implementation might want to do internally? Are there any interactions with proposed "strict mode" restrictions in ES3.1? How "future proof" is it relative to other features that are likely to be proposed for Harmony? Etc. Seriously, I'm not just trying to just blow you guys off. These are the sort of things I would want to work through before committing this feature to ES3.1 and I know that I don't have the time to do it and work on other things I have to get done for the 3.1 spec. I'd love to see somebody start to work through such details and discuss them here. But I think Harmony is the version you should be targeting. Allen > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:es-discuss- > [EMAIL PROTECTED] On Behalf Of William Edney > Sent: Sunday, August 17, 2008 8:51 PM > To: Maksim Lin > Cc: [email protected] > Subject: Re: A Proposal For Formalizing __noSuchMethod__ in ECMAScript > 3.1. > > Maks - > > My apologies. I was unaware that Rhino also implemented > __noSuchMethod__. That's great - the more the merrier. > > We've also communicated our desire to have a __noSuchMethod__ > implementation to the team currently doing the excellent Squirrelfish > work for Webkit, so maybe we'll see an implementation there too :-). > > Cheers, > > - Bill > > On Aug 17, 2008, at 9:36 PM, Maksim Lin wrote: > > >> This is currently a SpiderMonkey-only extension and we are proposing > >> that it be incorporated into ECMAScript 3.1. > > > > For what its worth, the current rhino engine also supports > > __noSuchMethod__. > > Though I wonder if it makes much of a difference since server-side js > > still seems to be the poor cousin that everyones keeps forgeting to > > invite to the party. > > > > Maks. > > _______________________________________________ > > 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 _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
