Last Comment Bug 670759 - Move prototype-creation shared by String/RegExp into one method
: Move prototype-creation shared by String/RegExp into one method
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
-- normal (vote)
: mozilla8
Assigned To: Jeff Walden [:Waldo] (remove +bmo to email)
: Jason Orendorff [:jorendorff]
Depends on:
  Show dependency treegraph
Reported: 2011-07-11 14:22 PDT by Jeff Walden [:Waldo] (remove +bmo to email)
Modified: 2011-07-12 17:27 PDT (History)
1 user (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (6.28 KB, patch)
2011-07-11 14:22 PDT, Jeff Walden [:Waldo] (remove +bmo to email)
bhackett1024: review+
Details | Diff | Splinter Review

Description User image Jeff Walden [:Waldo] (remove +bmo to email) 2011-07-11 14:22:10 PDT
Created attachment 545256 [details] [diff] [review]

Right now String/RegExp duplicate creation of their respective *.prototype objects, and of subsequent frobbing to get their empty shapes (which does not depend on its current ordering with respect to prototype or associated constructor creation).  Implement a helper method to do that, and to serve as a reasonable point for future work involved in initializing prototype objects (thinking particularly of TI here).

This method can't be used by JS_InitClass code path because this changes the parent of the prototype object to be the global object, and sometimes JS_InitClass is called with an object that's not the global object.  This parent dependency (which none of the standard classes has -- I know ctypes does, but I think the corresponding tests are just over-asserting out of an abundance of caution) will eventually die as part of bug 638316 (if not sooner), but for right now it's a mostly-unimportant side show.
Comment 1 User image Brian Hackett (:bhackett) 2011-07-11 15:33:40 PDT
Comment on attachment 545256 [details] [diff] [review]

Review of attachment 545256 [details] [diff] [review]:
Comment 2 User image Jeff Walden [:Waldo] (remove +bmo to email) 2011-07-11 16:24:56 PDT
Comment 3 User image Mounir Lamouri (:mounir) 2011-07-12 03:52:16 PDT
Comment 4 User image Jeff Walden [:Waldo] (remove +bmo to email) 2011-07-12 13:51:27 PDT
I should further note that this method can't be used by JS_InitClass now because it depends on the Array class being initialized with js_ArrayClass, the prototype for it being created with that class, the prototype then converting to js_SlowArrayClass when named properties are added to it, and js_SlowArrayClass then being used for the getEmptyShape call.  (I will be changing this facet of oddity at a future time, distinct from the parent-identity concern noted in comment 0.)
Comment 5 User image Jeff Walden [:Waldo] (remove +bmo to email) 2011-07-12 17:27:42 PDT
...and more differentiation (can you stand it?): if parent_proto (maybe protoProto, memory hazy about the name) is NULL when provided to JS_InitClass, for a non-standard class, then it becomes relevant that createBlankPrototype uses WithProto::Given while the current code uses WithProto::Class.  That distinction is even wrinklier to get rid of than parent identity, or Array speciality.  But subsequent changing can and does make JS_InitClass's code look somewhat more similar to that in createBlankPrototype, at least.

Note You need to log in before you can comment on or make changes to this bug.