dachev - patch it! :)
http://code.google.com/p/v8/wiki/Contributing

I am the original requestor for this enhancement to be added to the Mozilla codebase
years ago (back in 2003 actually). Therefore, I am very, very excited that you guys
add it to V8! ECMA e4 is now a dead branch of the language and the ECMA committee has
decided to move more slowly, starting with ECMA e5.

I would say that both the C-based Spidermonkey JS engine and the Java-based Rhino
engine have implemented __noSuchMethod__ and, for us ex-Smalltalkers, having a
'doesNotUnderstand'-like functionality is very empowering :-).

Here is the original URL in the Mozilla Bugzilla bug database that added support for it:

https://bugzilla.mozilla.org/show_bug.cgi?id=196097

I've attached the same test case file that I used for that bug here. It exercises the
hook quite well, especially 'scott's test'.

I've also proposed this to the ECMA committee and have attached that proposal to this
bug as another file. It explains the rationale for such a mechanism in detail.

Feel free to contact me for further details or for someone to test this when you add it!!

Thanks very much!

Cheers,

- Bill

(No comment was entered for this change.)

	nosuchmethodtest.html
	1.6 KB Download

	noSuchMethodProposal.txt
	3.7 KB Download

I created a toy V8 implementation, see the attached patch. Currently (r 2780) all JS
tests pass.

There is also a github tree which I try to keep up to date:
http://github.com/dachev/v8/tree/master

	__noSuchMethod__.diff
	1.8 KB Download

This is excellent news. Thank you!

Is there a process or procedure by which this can be included in the main V8 trunk so that it will appear in 
the next version of Chrome?

I would be happy to help with that, if I can. I am not a C developer (well, many years ago ;-) ), but I have done 
a lot of JavaScript work and would be happy to help with extra test cases or documentation or other things if 
that is what is necessary to get this moved into the main V8 code base.

Please let me know and thank you!

Cheers,

- Bill

Thanks for the patch.  However, there are a few issues that would have to be resolved 
before we could apply it.

There are some problems with the code itself but I'd be happy to help sort those out.  The biggest problem is that Safari's JavaScriptCore doesn't have this feature.  We 
attempt to be compatible with JSC so that people can expect that if their site works 
when in google chrome it will also work in safari.  If this feature were present in JSC 
then adding it in V8 would be a much easier decision for us.

Thanks for your offer to help!

Note the following Webkit Bugzilla bug:

https://bugs.webkit.org/show_bug.cgi?id=18058

I will express the concern here that, even though this bug was entered on March of 2008, and has been entered into Apple's 'radar' bug 
system, no action has been taken (which is unfortunate).

I would make the following argument to move forward with this feature now, even if JSC lacks it:

1. While it is admirable to try to be completely compatible with JSC, this feature is quite an 'advanced language feature' even for 
seasoned JavaScript programmers. I would argue that those who use it would be sophisticated enough to know that they're using a JS 
'language engine' feature and would know to test for V8 vs. JSC as opposed to 'I'm running on a Webkit browser'.

2. Note my comment on the Webkit bug regarding 'friendly competition' between the V8 and Nitro engine. In my opinion, it is that 
competition that drives things forward (look at the effect V8 has had on other vendors making their engines *much* faster). If 
everyone was waiting for everyone else to upgrade, you would end up with the classic 'chicken and egg' problem. If V8 gets this patch, 
then there's a stronger argument to the Safari/Nitro team to add it.

3. V8 has a patch (or at least a start on a patch) available now. This patch has been kept up-to-date with the latest V8 code.

4. This patch is a low-impact patch both in terms of code size and effect on speed of JavaScript execution.

I will continue to prod the Safari/Nitro team to add this feature, offering a bottle of wine to those who take up the challenge (I've done 
this for the Mozilla project and had some success :-) ). I will make the same offer here, BTW :-).

I would ask you all to please consider these arguments I have made here and add this very powerful feature to V8 for those of us to 
whom this would make a *huge* difference in code size and complexity.

Cheers,

- Bill

I do sort of see your point about this being an advanced feature but on the other hand I'm sure the 
road to the incompatibility nightmare we have now was paved with arguments like that.  We don't want 
people to ever have to test for v8 vs. jsc.  And ECMAScript 5 demonstrates you don't need the 
individual implementations to forge ahead with new language features on their own for the language to 
evolve.

Chris, I completely understand your compatibility concerns but I think it is not very
likely this will break anyone's (browser) code except maybe in a few cases where a
long list of circumstances are at place.

I'm sure the team is also concerned about maintenance as there are no truly "free"
features. However, in my (modest) experience with V8 it seems that the code is
designed very well and allows for a single-point, low-maintenance implementation
which can be kept in check with unit testing and minimal (if any) coding effort.

I think __noSuchMethod__ will be most compelling for server-side JS developers. In
this realm V8 enjoys immense popularity. I guess what I'm getting at is that V8 is
not just Chrome's JS engine. The community loves it and projects that have started to
embed abound.

Writing this comment, I truly believe that __noSuchMethod__ is not just one of those
"cool" language features you can brag about while talking to other developers but end
up rarely used in practice. Its utility was proven on a large scale by Ruby's Active
Record and might turn out to be what server-side JS needs to finally take off.

In light of the above two paragraphs if the team still doesn't feel comfortable with
__noSuchMethod__ in Chrome we can allow it per run-time or compile-time configuration
for the people that embed.

Given some direction, it would be an honor for me to implement a proper patch.

Best regards,
Blago

I'm sorry to have to disappoint here but it's just not possible as things stand.  The 
best advice I can give you is to contribute an implementation to JSC.

Oh well, we had to try :-)

The Nitro implementation I played with a few months ago feels a bit hacky so I'll try
to create a new one this fall and have it accepted.

@Christian - I totally understand your point. We'll work this from 'the other end of the tunnel', so to speak :-). 
We'll be back :-).

@dachev - Wow! You already had a Nitro implementation? That's great! Please note that I've added a 'bottle of your 
favorite wine' bounty to the bug in Webkit's Bugzilla engine. I'll do the same here. So that's 2 bottles of wine (no 
Dom Perignon, please ;-) ) to be earned, not to mention the accolades of peers and me and my team's unending 
gratitude.

One thing I would mention here is that, since I'm building a browser-based app, implementing this for V8 but then 
not having it show up in Chrome would be somewhat useless for me.

Having said that, let me know if there is anything else I can do to help with regards to the V8 or Nitro 
implementations of this feature. If you sign up for the bug on Webkit's Bugzilla engine, we can carry on this 
conversation there :-).

Thanks to all!!

Cheers,

- Bill