WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 25617
23810
Multiple inheritance costs too much for HTMLInput/Option/.../SelectElement
https://bugs.webkit.org/show_bug.cgi?id=23810
Summary
Multiple inheritance costs too much for HTMLInput/Option/.../SelectElement
Nikolas Zimmermann
Reported
2009-02-06 17:23:46 PST
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
Comment 1
2009-02-06 17:45:37 PST
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
Comment 2
2009-05-08 12:13:47 PDT
This bug has been fixed yesterday. *** This bug has been marked as a duplicate of
25617
***
Lucas Forschler
Comment 3
2019-02-06 09:03:02 PST
Mass moving XML DOM bugs to the "DOM" Component.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug