Re: [gentoo-dev] rfc: eclass issues

[Rich Freeman <rich0@gentoo.org>]

On Sun, Aug 17, 2014 at 11:38 AM, William Hubbs <williamh@gentoo.org> 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