Closed Bug 664577 Opened 9 years ago Closed 9 years ago

Fix inclusion of jsobj.h in Content code due to ArrayBuffer optimizations

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: nsm, Assigned: nsm)

References

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: 

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.

Reproducible: Always
Comment on attachment 539672 [details] [diff] [review]
API fix

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?
Attachment #539672 - Flags: review+
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Attached patch API fixSplinter Review
Inline implementation is kept part of the class.
Attachment #539672 - Attachment is obsolete: true
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.
Assignee: general → nsm.nikhil
http://hg.mozilla.org/tracemonkey/rev/8b3dc129aed8

I didn't add the bug # to the checkin message, sadly :-/.
Whiteboard: fixed-in-tracemonkey
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.