Last Comment Bug 691992 - Fully split up {g,s}etAttributes into property/element/special/generic forms
: Fully split up {g,s}etAttributes into property/element/special/generic forms
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla10
Assigned To: Jeff Walden [:Waldo] (remove +bmo to email)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-04 17:52 PDT by Jeff Walden [:Waldo] (remove +bmo to email)
Modified: 2011-10-20 03:05 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (31.26 KB, patch)
2011-10-04 17:52 PDT, Jeff Walden [:Waldo] (remove +bmo to email)
bhackett1024: review+
Details | Diff | Review

Description Jeff Walden [:Waldo] (remove +bmo to email) 2011-10-04 17:52:49 PDT
Created attachment 564718 [details] [diff] [review]
Patch

This is pretty dreary, but it'll help with splitting up the work to split property representation into elements and non-elements, so on we go.
Comment 1 Brian Hackett (:bhackett) 2011-10-06 07:42:07 PDT
Comment on attachment 564718 [details] [diff] [review]
Patch

General comment:

It seems weird for Classes to have hooks for both generic accesses and specific kinds of accesses (e.g. array_getGenericAttributes vs. array_getPropertyAttributes), especially when they either duplicate functionality or defer to one another in a hand-rolled way (e.g. proxy_SetPropertyAttributes).  This seems unnecessarily verbose; could either the generic or the specialized methods be removed from Class?  My preference would be to remove the latter and just have the generic form, as then the Class interface would be largely unchanged from before property splitting (right?).
Comment 2 Jeff Walden [:Waldo] (remove +bmo to email) 2011-10-19 11:32:26 PDT
(missed the review mail originally, wonder how many other of these I missed... :-\ )

The generic interfaces will go away eventually, and the specialized ones will be all that remain.  It's just easier, for now, to leave the generic versions in place so as not to have to invasively touch quite as many users, especially when some of those users will go away completely when the property-element split happens.
Comment 3 Jeff Walden [:Waldo] (remove +bmo to email) 2011-10-19 14:10:02 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/5a848c512af7
Comment 4 Marco Bonardo [::mak] 2011-10-20 03:05:05 PDT
https://hg.mozilla.org/mozilla-central/rev/5a848c512af7

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