On 17 August 2014 19:03, Michał Górny <mgo...@gentoo.org> wrote:
>
> > So if you could sculpt it to be broader by default and have less scope
> for
> > developer error, that'd be an improvement.
> >
> > --- code start --
> > ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack"
> > inherit foo bar baz
> >
> >
> > --- code end ---
> >
> > here, src_unpack would be baz_src_unpack *regardless* of composition
> order
> > because "foo" and "bar" were barred from being used, and baz took
> > precedence as a result.
>
> Wow, so you suggest replacing a solution where you have to re-declare
> all the phases with one in which you have to opt-out of all phases of
> all eclasses...
>
> This thread spreads more great ideas every minute. Soon enough, we will
> ban eclasses and require every ebuild to write everything inline just
> to be sure. Preferably using kernel calls from assembly to avoid as much
> middleware as possible, and make ebuilds as verbose as possible.
Indeed, I think I shall recall my suggestion, because the number of times
you *ever* want to express that in eclasses is rare and none.
Either you want to expressly say "I want these phases to run in this order,
regardless of the import ordering", or "I want some sensible default to
take place based on import ordering"
Saying "I want this subset of possible phases to not happen, but we might
anticipate that somebody creates a function later that breaks our class and
that be ok"
Who ever does that. Seriously.
You would literally be enumerating ( @INHERITED - THEONEIWANT ) every
time when you could simply declare the one you want by doing " function(){
THEONEIWANT }".
In short, "Just override the function if you need to" is about as simple
and straight forward and not mental gymnastics as you're going to get.
Otherwise we're just paving a superhighway with good-intention-tiles.
--
Kent
*KENTNL* - https://metacpan.org/author/KENTNL
