Bug 23810
| Summary: | Multiple inheritance costs too much for HTMLInput/Option/.../SelectElement | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Nikolas Zimmermann <zimmermann> |
| Component: | DOM | Assignee: | Nikolas Zimmermann <zimmermann> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | cdumez, darin, eric, hyatt, mjs, sam, staikos |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.5 | ||
Nikolas Zimmermann
Recently some ABCs have been introduced to give the render tree an abstract access to form control elements, so RenderTextControl/RenderListBox/etc. can be used from outside HTML (before those classes depended on HTMLSelectElement/HTMLInputElement directly).
The simple & dirty approach I've chosen, costs too much memory, as Dave & Sam pointed out in private talks, while I argued the waste is low (real-life pages don't use thousands of input/select elements), but still it hurts HTML, and is only of benefit for WML (at least at the moment, and it's even turned off by default). So it only hurts HTML without giving it any benefit, besides a cleaner interface to the render tree.
One approach, floating in my mind is just to have _one_ FormControlElement class, replacing InputElement/OptionElement/OptionGroupElement/FormControlWithStateElement/SelectElement. All methods could be moved in this central class for form control elements, not as pure-virtual methods, but as virtual-methods defaulting to 'ASSERT_NOT_REACHED'. We could add some boolean methods isInputElement/isOptionElement to differentiate between the types of form control elements.
This would only add 4-bytes to HTMLInputElement, etc, which is really low, and it gives huge benefits for WML (able to reuse the Render* classes for form control elements). Currently ie. HTMLInputElement derives from HTMLFormControlElementWithState (deriving from HTMLElement, FormControlElementWithState, FormControlElement) and InputElement, which is 12-bytes.
That's just _one_ idea, this bug is meant as a container to discuss the future of this code.
I'm filing this bug, to adress I'm aware of the current limitations of the design, and I'm willing to improve it, after I get some input, where the journey should end.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Darin Adler
Another idea is to find a way to make the functions non-virtual in builds without HTML. InputElement would become a typedef for HTMLInputElement and we'd include all the appropriate functions, perhaps by inheriting from a base class, but they would not be virtual functions.
Nikolas Zimmermann
This bug has been fixed yesterday.
*** This bug has been marked as a duplicate of 25617 ***
Lucas Forschler
Mass moving XML DOM bugs to the "DOM" Component.