On Sun, Aug 17, 2014 at 11:38 AM, William Hubbs <[email protected]> wrote: > > The other concern he mentioned was indirectly inherited eclasses being > able to override phase functions. >
So, while I'm not sure whether getting rid of the ability to inherit phase functions is practical/good/etc, I do think we need to think hard on just what the purpose of an eclass is. This is painting with broad strokes, but I do think there is a case for distinguishing between eclasses used to simplify a large number of closely-related packages (kde/x11/etc), and one used to provide general support to a broad colleciton of packages (python, perl, etc - just about anything named after a language for starters). For the specialized case the inheritance usually isn't a problem, since the packages that inherit it are well-controlled, and while I'm not sure why multiple inheritance is really needed for phase functions, it probably won't be problematic since the use is so well controlled. For eclasses that are broadly used, I think that even inheritance of one layer of phase functions is problematic, let alone multiple ones. What if the same eclass gets pulled in multiple times, etc? Heck, we didn't even want to override things when implementing user patches - we agreed to put it in the default function, and require it to be called when it is overridden, but we didn't aim to automatically call it when it is overriden because of the risk of problems. Why do we need multiple inheritance of phase functions at all? I can see the convenience of allowing one layer, but I think we should consider it a best-practice to avoid it in broadly-used eclasses, unless there is a really good reason not to. Rich
