Fully split up {g,s}etAttributes into property/element/special/generic forms

RESOLVED FIXED in mozilla10

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Waldo, Assigned: Waldo)

Tracking

unspecified
mozilla10
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
Attachment #564718 - Flags: review?(bhackett1024)
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?).
Attachment #564718 - Flags: review?(bhackett1024) → review+
(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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5a848c512af7
Target Milestone: --- → mozilla10
https://hg.mozilla.org/mozilla-central/rev/5a848c512af7
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.