Could we patch V8 to allow for __noSuchMethod__?

[Tim Caswell]

While trying to design a good persistence library I've looked around to see what's already there in the browser world. The api's developed for things like localStorage and mongodb can't be implemented in pure javascript without a method missing hook and/or making [] be an overridable method like it is in ruby.

I noticed that Mozilla's engine added __noSuchMethod__ a while back. It's looks like a great method missing style hook. There is a patch for V8 already that's maintained to keep up with V8's progress. But the V8 guys won't accept it because it's not compatible with JSC. Since we're not in a browser and could care less about JSC compatibility, is it kosher to add patches to V8 itself as part of node?

http://github.com/dachev/v8 - v8 fork with __noSuchMethod__ added
http://code.google.com/p/v8/issues/detail?id=264 - issue where V8 refused to include patch.

If we don't want this in node proper, is there a way to make it an add on, or at the least, could someone help me make a fork of node that has it patched in?

[Bluebie]

I agree that V8, and by extension, node, should support
__noSuchMethod__ until such time as a standards body proposes a better
alternative. Would this really resolve the localStorage issue though?
The naming makes it sound as though this wouldn't be useful for
creating a global property getter, as the property needs to be called
for the function to activate?

On Dec 9, 9:38 am, Tim Caswell <t...@creationix.com> wrote:
> While trying to design a good persistence library I've looked around to see what's already there in the browser world.  The api's developed for things like localStorage and mongodb can't be implemented in pure javascript without a method missing hook and/or making [] be an overridable method like it is in ruby.  
>
> I noticed that Mozilla's engine added __noSuchMethod__ a while back.  It's looks like a great method missing style hook.  There is a patch for V8 already that's maintained to keep up with V8's progress.  But the V8 guys won't accept it because it's not compatible with JSC.  Since we're not in a browser and could care less about JSC compatibility, is it kosher to add patches to V8 itself as part of node?
>

> http://github.com/dachev/v8- v8 fork with __noSuchMethod__ addedhttp://code.google.com/p/v8/issues/detail?id=264- issue where V8 refused to include patch.

[Ryan Dahl]

On Tue, Dec 8, 2009 at 11:38 PM, Tim Caswell <t...@creationix.com> wrote:
> While trying to design a good persistence library I've looked around to see what's already there in the browser world.  The api's developed for things like localStorage and mongodb can't be implemented in pure javascript without a method missing hook and/or making [] be an overridable method like it is in ruby.
>
> I noticed that Mozilla's engine added __noSuchMethod__ a while back.  It's looks like a great method missing style hook.  There is a patch for V8 already that's maintained to keep up with V8's progress.  But the V8 guys won't accept it because it's not compatible with JSC.  Since we're not in a browser and could care less about JSC compatibility, is it kosher to add patches to V8 itself as part of node?

Not for language feature enhancements, sorry. I want node to use
vanilla javascript.

[Bluebie]

The thing which bothers me about that perspective is that in the
browser, we already have APIs exposed to javascript, which are
impossible to implement in vanilla javascript, like localStorage and
document.all, and that these APIs are so clearly the nicest way to
write the types of code we're building, and yet they are only possible
for those who write in C. I dislike the idea that useful functionality
would only be available to those writing their machinery in C to be
quite uncomfortable, if familiar. At least to me, the essence of
node.js is that I don't have to choose between performance and
wonderful joyful code anymore. This deficiency stands in the way of
the later.

[Ray Morgan]

I agree with Ryan on this topic, and prefer sticking with vanilla v8.
All of those features that the browser implements are simply native
extension, and not language features. I think as the need arises
people will develop C libs for Node.js that others not as proficient
[in C] can use and learn from.

-Ray

> --
>
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en
> .
>
>

[Tim Caswell]

I understand the desire to not patch v8 directly. I wonder if it would be possible to write a node extension that added in the method missing or property get/set to the language. A more general question would be how much language could we even modify through node extensions.

[Tim Caswell]

By the way, v8 has nothing against including the patch as long as JSC from webkit has it first. There were some people working to get it included there, so we can hope.

[Daniel N]

Awesome :)

 

[Rakesh Pai]

This is a tough one. __noSuchMethod__ is great for building any kind of DSL. For example, Rails used/uses the equivalent of this all over the place to make things like the ORM super easy to use.

Any idea if this can be built as an extension to V8 that plugs in externally?

--

You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

--
Rakesh Pai
Mumbai, India.
http://piecesofrakesh.blogspot.com/
http://twitter.com/rakesh314
http://www.google.com/profiles/rakeshpai

[Patrick Mueller]

The WebKit bug is here:

Bug 18058: JS feature request: __noSuchMethod__
https://bugs.webkit.org/show_bug.cgi?id=18058

Vote on it, or add a comment, if you're interested.

On Dec 8, 2009, at 9:47 PM, Tim Caswell wrote:

> By the way, v8 has nothing against including the patch as long as JSC from webkit has it first. There were some people working to get it included there, so we can hope.
>
>
> On Dec 8, 2009, at 5:30 PM, Bluebie wrote:
>
>> I agree that V8, and by extension, node, should support
>> __noSuchMethod__ until such time as a standards body proposes a better
>> alternative. Would this really resolve the localStorage issue though?
>> The naming makes it sound as though this wouldn't be useful for
>> creating a global property getter, as the property needs to be called
>> for the function to activate?

Patrick Mueller - http://muellerware.org/

[Erik Corry]

2009/12/9 Rakesh Pai <rake...@gmail.com>:

> This is a tough one. __noSuchMethod__ is great for building any kind of DSL.
> For example, Rails used/uses the equivalent of this all over the place to
> make things like the ORM super easy to use.
> Any idea if this can be built as an extension to V8 that plugs in
> externally?

The necessary hooks are not present in the API, sorry.

[Matthew Kanwisher]

Method missing is incredibly useful for creating activerecord style orm. The other option is to pre generate all the methods you would need in advance, which might make for some giant vtables not sure how much slower the performance would be. I'm seriously thinking about hacking out an ORM solution for Node.js however I'm wondering if something like memcache would be a more useful interface, since most node apps are going to be notification engines.

~Matt

[Micheil Smith]

I'm also planing to write a form of ORM, especially after just seeing
the good looking work from Eric Fredricksen. Maybe we should collaborate
on ideas at some stage?

- Micheil.

Matthew Kanwisher wrote:
> Method missing is incredibly useful for creating activerecord style
> orm. The other option is to pre generate all the methods you would
> need in advance, which might make for some giant vtables not sure how
> much slower the performance would be. I'm seriously thinking about
> hacking out an ORM solution for Node.js however I'm wondering if
> something like memcache would be a more useful interface, since most
> node apps are going to be notification engines.
>
> ~Matt
>
> On Wed, Dec 9, 2009 at 6:18 AM, Erik Corry <erik....@gmail.com
> <mailto:erik....@gmail.com>> wrote:
>
> 2009/12/9 Rakesh Pai <rake...@gmail.com

> <mailto:rake...@gmail.com>>:

> <mailto:nod...@googlegroups.com>.

> >> To unsubscribe from this group, send email to
> >> nodejs+un...@googlegroups.com

> <mailto:nodejs%2Bunsu...@googlegroups.com>.

> >> For more options, visit this group at
> >> http://groups.google.com/group/nodejs?hl=en.
> >
> >
> >
> > --
> > Rakesh Pai
> > Mumbai, India.
> > http://piecesofrakesh.blogspot.com/
> > http://twitter.com/rakesh314
> > http://www.google.com/profiles/rakeshpai
> >
> > --
> >
> > You received this message because you are subscribed to the
> Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com

> <mailto:nod...@googlegroups.com>.

> > To unsubscribe from this group, send email to
> > nodejs+un...@googlegroups.com

> <mailto:nodejs%2Bunsu...@googlegroups.com>.

> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en.
> >
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com

> <mailto:nod...@googlegroups.com>.

> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com

> <mailto:nodejs%2Bunsu...@googlegroups.com>.

[Isaac Z. Schlueter]

I'd recommend against node patching v8 unless absolutely necessary.
Don't get me wrong, I think __methodMissing__ is a great idea, and
I've voted for this functionality on the v8 and webkit bugs. But it's
not strictly necessary from a functionality pov.

It's already possible to write a function that takes a method name as
the first param. What can't you do this way that you can do with
__methodMissing__? It's a bit uglier, to be sure, but JavaScript is a
little bit ugly at times, and I think that, while that's not ideal,
it's not completely terrible either.

There are issues with adding __methodMissing__ to the language
specification, and anyone who's serious about seeing this implemented
should try to go have that discussion in the ES groups. In my
opinion, that's where this should happen, not in a project like node.

</$0.02>

On Dec 10, 4:24 am, Micheil Smith <mich...@brandedcode.com> wrote:
> I'm also planing to write a form of ORM, especially after just seeing
> the good looking work from Eric Fredricksen. Maybe we should collaborate
> on ideas at some stage?
>
> - Micheil.
>
> Matthew Kanwisher wrote:
> > Method missing is incredibly useful for creating activerecord style
> > orm. The other option is to pre generate all the methods you would
> > need in advance, which might make for some giant vtables not sure how
> > much slower the performance would be. I'm seriously thinking about
> > hacking out an ORM solution for Node.js however I'm wondering if
> > something like memcache would be a more useful interface, since most
> > node apps are going to be notification engines.
>
> > ~Matt
>

> > On Wed, Dec 9, 2009 at 6:18 AM, Erik Corry <erik.co...@gmail.com
> > <mailto:erik.co...@gmail.com>> wrote:
>
> >     2009/12/9 Rakesh Pai <rakesh...@gmail.com
> >     <mailto:rakesh...@gmail.com>>:

> >     > This is a tough one. __noSuchMethod__ is great for building any
> >     kind of DSL.
> >     > For example, Rails used/uses the equivalent of this all over the
> >     place to
> >     > make things like the ORM super easy to use.
> >     > Any idea if this can be built as an extension to V8 that plugs in
> >     > externally?
>
> >     The necessary hooks are not present in the API, sorry.
>

> >     > On Wed, Dec 9, 2009 at 12:06 AM, Daniel N <has....@gmail.com

> >     <mailto:has....@gmail.com>> wrote:
>
> >     >> On Wed, Dec 9, 2009 at 10:36 AM, Ryan Dahl

[Dean Landolt]

On Thu, Dec 10, 2009 at 12:10 PM, Isaac Z. Schlueter <i...@foohack.com> wrote:

I'd recommend against node patching v8 unless absolutely necessary.
Don't get me wrong, I think __methodMissing__ is a great idea, and
I've voted for this functionality on the v8 and webkit bugs.  But it's
not strictly necessary from a functionality pov.

It's already possible to write a function that takes a method name as
the first param.  What can't you do this way that you can do with
__methodMissing__?  It's a bit uglier, to be sure, but JavaScript is a
little bit ugly at times, and I think that, while that's not ideal,
it's not completely terrible either.

There are issues with adding __methodMissing__ to the language
specification, and anyone who's serious about seeing this implemented
should try to go have that discussion in the ES groups.  In my
opinion, that's where this should happen, not in a project like node.

</$0.02>

And if you really do care about seeing this functionality as part of ES there's a proposal being kicked around we speak:

https://mail.mozilla.org/pipermail/es-discuss/2009-December/010250.html

[Matthew Kanwisher]

Usually new features are added to a language as outlier groups use them and prove that they are useful. Its hard to start at the committee level to add a new feature. You need to show real world examples and then slowly it gets posted back to the standards bodies, think Google Gears and What-WG. If you have a suggestion on how to implement __methodMissing__ in stock javascript even if its ugly, I think that would be a great start

~Matt

On Thu, Dec 10, 2009 at 12:10 PM, Isaac Z. Schlueter <i...@foohack.com> wrote:

[Andrew Lunny]

I don't think you can implement __noSuchMethod__ in method calls of the form:
object.method();

The best you can do is:
object.exec("methodIdentifier");
or
object.apply("methodIdentifier",[arguments]);

I think this is what Isaac means by the ugly form; here is some sample code:
http://gist.github.com/253533

Andrew Lunny
Software Developer, Nitobi
604 685 9287
andrew...@nitobi.com

[Rakesh Pai]

I haven't thought this through in detail, but Object.exec brings along problems of scoping and scope binding, or the utter lack of them. Not entirely natural to JS.

[Erik Corry]

2009/12/10 Rakesh Pai <rake...@gmail.com>:

> I haven't thought this through in detail, but Object.exec brings along
> problems of scoping and scope binding, or the utter lack of them. Not
> entirely natural to JS.

I imagine it would look something like this:

Foo.prototype.exec = function(name, args) {
if (name in this) {
// Use call or apply to call.
} else {
this.__noSuchMethod__(name, args);
}
}

I can't see what you mean with problems with scoping. Can you explain.

What I like about this is that it allows two different
__noSuchMethod__ mechanisms on the same objects. You could define
exec2 and __noSuchMethod2__ and do it all again. So it's not so much
a once-only trick.

[Rakesh Pai]

What I meant is that exec in the semantics that Andrew mentioned would make it hard to have closure scope, and the binding of "this" to the scope of the executed function, with or without lexical scope. This is similar to an eval (without the mozilla extensions to eval) in the sense of the scope in which it operates. This sucks, and it's not natural to JS.

[Blago]

Hello,
I'm the author of the V8 __noSuchMethod__ patch and I'll try to
summarize the current state of affairs:
1) It is of paramount importance for V8 to be as compatible with
Webkit as possible and they will not add the feature first.

2) We have not seen any indication that Webkit people are even
remotely interested and this is understandable -- more code to
maintain that is not even part of the standard. Moreover, the webkit
implementation will be a LOT more involved than the V8 one. My
(private) proof-of-concept webkit patch involved a number of
additional files, opcodes, changes. The bottom line: they won't do it.

What now? In my wildest dreams V8 is somehow convinced to add the
feature, and then Webkit follows out of fear they are falling behind.
Realistically, no one will touch their VMs for any reason other than
performance until Harmony is out. So this is our best bet.

I agree that nodejs should use a vanilla V8. However I believe it
would be possible to get most of what __noSuchMethod__ has to offer
through a module. It can be done by using special (C++ backed) objects
with named property interceptors. The downside is that since we cannot
know in advance how will an unknown property be used (will it be
called?) the interceptor will always have to return __noSuchMethod__.
This means that the object will never have an undefined property which
could lead to sneaky coding mistakes. All in all I thing it's an
interesting idea and may give it a try (spare time disclaimer goes
here).

On Dec 8, 4:38 pm, Tim Caswell <t...@creationix.com> wrote:
> While trying to design a good persistence library I've looked around to see what's already there in the browser world.  The api's developed for things like localStorage and mongodb can't be implemented in pure javascript without a method missing hook and/or making [] be an overridable method like it is in ruby.  
>
> I noticed that Mozilla's engine added __noSuchMethod__ a while back.  It's looks like a great method missing style hook.  There is a patch for V8 already that's maintained to keep up with V8's progress.  But the V8 guys won't accept it because it's not compatible with JSC.  Since we're not in a browser and could care less about JSC compatibility, is it kosher to add patches to V8 itself as part of node?
>

> http://github.com/dachev/v8- v8 fork with __noSuchMethod__ addedhttp://code.google.com/p/v8/issues/detail?id=264- issue where V8 refused to include patch.

[Johan Sørensen]

On Tue, Dec 8, 2009 at 11:38 PM, Tim Caswell <t...@creationix.com> wrote:
> While trying to design a good persistence library I've looked around to see what's already there in the browser world.  The api's developed for things like localStorage and mongodb can't be implemented in pure javascript without a method missing hook and/or making [] be an overridable method like it is in ruby.

Sounds like you're doing it wrong. As long as you can get whatever
data comes out of your backend into an object structure you're set.
Setters? No problem, just build them based on said object keys. Not
even activerecord (the ruby lib) uses ruby's method_missing for the
attribute getter/setters any more, it generates them when it asks for
the table structure.

Cheers,
JS

[Erik Corry]

2009/12/10 Rakesh Pai <rake...@gmail.com>:

> What I meant is that exec in the semantics that Andrew mentioned would make
> it hard to have closure scope, and the binding of "this" to the scope of the
> executed function, with or without lexical scope. This is similar to an eval
> (without the mozilla extensions to eval) in the sense of the scope in which
> it operates. This sucks, and it's not natural to JS.

Can you give a code example of something that would work with
__noSuchMethod__ that can't be done with exec to help me understand?

[Rakesh Pai]

For example:

function MyConstructor() {

    (function() {

        var someVariable = 0;

        this.__noSuchMethod__ = function() {

            someVariable++;

        })

    }).apply(this, []);

}

Forget the fact that this is useless code (someVariable is incremented every time an unknown method is called on an instance of MyConstructor). However, what I want to highlight is (1) that someVariable is available to __noSuchMethod__ in closure scope and is not local to the entire MyConstructor, and (2) that the meaning of ``this" within the outer (function() {}) is redefined by using apply to bind it to the scope of MyConstructor.

I am not sure if exec can do that, since it's scope binding cannot be specified externally, and it's not clear where the execution context will lie as far as closure scope availability is concerned. But maybe I'm just missing something.

[Andrew Lunny]

Rakesh makes a good point about closure scope - it would be better to
have the exec method point to a noSuchMethod function in the
constructor that can access closed variables. Here's a modified gist:
http://gist.github.com/253533

If an object is created with the new operator, all functions defined
in the prototype are set as methods on the new object, and their
"this" variable points to the newly created object. I don't think
context is any more of an issue than with any other prototypal method
call.

Cheers,
Andrew

p.s. I'm a little confused by Rakesh's code sample; what's the
difference between:
function x() {
// some statements;
}
and
function x() {
(function () {
// some statements
}).apply(this,[]);
}
The second one looks completely redundant to me, a la:
var x = 5;
x = x;