User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Since ArrayBuffer was collapsed into a JSObject by bug 656519, content and DOM code which used it required the inclusion of jsobj.h, which is frowned upon :)
This patch creates two versions of the public API for ArrayBuffer, JS_GetArrayBufferByteLength and JS_GetArrayBufferData which are not-inline and can be used treating JSObject as opaque, while js_GetArrayBufferByteLength and js_GetArrayBufferData are used by the engine.
Created attachment 539672 [details] [diff] [review]
Comment on attachment 539672 [details] [diff] [review]
My only thought is that you could let the inlined versions still be member functions on ArrayBuffer (and let them simply be undefined for consumers outside the engine) and simply defined in jstypedarrayinlines.h. Do you have feelings one way or the other?
I put them as functions for consistency. Both private and public have the same name except for js/JS.
> My only thought is that you could let the inlined versions still be member
> functions on ArrayBuffer
Fwiw, this was my assumption about how we'd do it.
Created attachment 539834 [details] [diff] [review]
Inline implementation is kept part of the class.
Yeah, the consistency is a hold-over from the pre-C++ days of SpiderMonkey. We're migrating more and more towards class methods over js_* methods.
I didn't add the bug # to the checkin message, sadly :-/.
Back it out and reland with the bug#?
But it's not clear why that wasn't there to start with....
http://hg.mozilla.org/tracemonkey/rev/ca93cfe414a0 <-- backout
http://hg.mozilla.org/tracemonkey/rev/e3c7aa315ca5 <-- relanding
Nikhil, in general, when you write your commit messages for patches, please include the bug # in the commit message. It make it easier when doing hg archaeology to tie specific commits to bugs.
cdleary-bot mozilla-central merge info: