1 |
On Sun, Aug 17, 2014 at 11:38 AM, William Hubbs <williamh@g.o> wrote: |
2 |
> |
3 |
> The other concern he mentioned was indirectly inherited eclasses being |
4 |
> able to override phase functions. |
5 |
> |
6 |
|
7 |
So, while I'm not sure whether getting rid of the ability to inherit |
8 |
phase functions is practical/good/etc, I do think we need to think |
9 |
hard on just what the purpose of an eclass is. |
10 |
|
11 |
This is painting with broad strokes, but I do think there is a case |
12 |
for distinguishing between eclasses used to simplify a large number of |
13 |
closely-related packages (kde/x11/etc), and one used to provide |
14 |
general support to a broad colleciton of packages (python, perl, etc - |
15 |
just about anything named after a language for starters). |
16 |
|
17 |
For the specialized case the inheritance usually isn't a problem, |
18 |
since the packages that inherit it are well-controlled, and while I'm |
19 |
not sure why multiple inheritance is really needed for phase |
20 |
functions, it probably won't be problematic since the use is so well |
21 |
controlled. |
22 |
|
23 |
For eclasses that are broadly used, I think that even inheritance of |
24 |
one layer of phase functions is problematic, let alone multiple ones. |
25 |
What if the same eclass gets pulled in multiple times, etc? |
26 |
|
27 |
Heck, we didn't even want to override things when implementing user |
28 |
patches - we agreed to put it in the default function, and require it |
29 |
to be called when it is overridden, but we didn't aim to automatically |
30 |
call it when it is overriden because of the risk of problems. |
31 |
|
32 |
Why do we need multiple inheritance of phase functions at all? I can |
33 |
see the convenience of allowing one layer, but I think we should |
34 |
consider it a best-practice to avoid it in broadly-used eclasses, |
35 |
unless there is a really good reason not to. |
36 |
|
37 |
Rich |