568731 - TM: rename JSNoopProxyHandler to JSWrapper and move it into jswrapper.[h|cpp]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Andreas Gal :gal]

This file will hold our new membranes and wrapper code.

Comment 1

[Andreas Gal :gal]

Attachment: patch

Comment 2

[Andreas Gal :gal]

Review ping.

Comment 3

[Chris Leary [:cdleary] (not checking bugmail)]

Comment on attachment 447899 [details] [diff] [review]
patch

The singleton wrapper object is a static member of the |JSWrapper| class, so calling |JSWrapper::wrap| will only ever resolve to |JSWrapper::construct| when |singleton.construct| is called in that function -- I don't think that's what we want. The interface that was in there before, |JSWrapper<typename T extends JSWrapper>::wrap| seems to make the most sense, so you can grab |T::singleton| like it was doing. You can expose this kind of thing across C API boundaries by making a helper function per wrapper class that does something like |NopWrap = JSWrapper<JSWrapper>::wrap|.

The interface for JSNoopProxyHandler is still in there, should rip that out too.

The naming is getting confusing -- in ::wrap you have |JSWrapper *handler, JSObject *wrapper|. I get that the wrapper is the JS-land wrapper object, but still makes me double take. :-)

Classes in namespace js don't need a JS prefix, but that's probably for another bug.

Comment 4

[Andreas Gal :gal]

Attachment: patch

Comment 5

[Andreas Gal :gal]

I will leave a more complex solution to wrap() to a follow-up patch that actually specializes wrappers.

Comment 6

[Andreas Gal :gal]

http://hg.mozilla.org/tracemonkey/rev/caf9170f2971

Comment 7

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/caf9170f2971