Bug 47884
| Summary: | should we allow multiple inheritance in python code in webkit? | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Dirk Pranke <dpranke> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | abarth, eric, levin, ojan, tony |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
Dirk Pranke
See bug 47874 for some background ... there are places in the code where using MI would make the code cleaner, like webkitpy/layout_tests/port/{google_chrome,chromium_gpu}.py , where the classes naturally want some sort of diamond and/or mixin behavior, and we resort to unpleasantness in its absence.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Adam Barth
We use multiple inheritance in a bunch of places in webkitpy, mostly int the Mixin pattern.
Adam Barth
Actually, also to inherit from "pure virtual" interfaces.
Tony Chang
I'm fine with pure virtual interfaces and to a lesser degree, mixin.
The proper way to refactor the google_chrome and chromium_gpu ports would be to have delegate classes for specific functionality of a port. For example, having a delegate that provides a few path functions (e.g., baseline search path and path to expectations) and have it be a member variable of Port. This could also be done via mixins, but I think the delegate pattern is more widely used in WebKit code.
Tony Chang
To clarify, I think what we want to avoid is a GPU port and a Linux port where we inherit from both to make a Linux GPU port. That would be confusing because you don't know what functions are provided by which base class.
Dirk Pranke
I think I will consider this closed as "yes, with caution". Anyone please reopen or comment if you disagree :)