On 17 August 2014 09:54, William Hubbs <willi...@gentoo.org> wrote: > I strongly oppose this change, because I feel it will make our > entire tree very unpredictable at best. I realize this might eliminate > boilerplating from our tree. Weighing that against the possible > ramifications in this big of a change in automagic behaviour, I think > the cost is much higher than the gain. > >
I agree on that part, for what its worth. The current system we have in place is an analogue of "role based" or "trait based" inheritance, where you have very straight forward composition behavior with regards to the final ebuild. One of the parent classes "wins", and if you don't like this, you have to adapt it manually. This in practice usually proves more useful than diamond style multiple inheritance, that while seeming like a nice idea in concept, in practice proves more complicated than its worth. The only downside I see is we don't have a clear straight forward collision strategy, which is essential for most role based systems: For instance, dog.eclass : function bark tree.eclass: function bark Proves not to be resolvable automatically in a sensible way. Collison systems I've seen usually do one of two things: - In the event of a collision, demand the consumer resolve the problem by redefining the function the collision occurs on in terms of its composite parts. ( which is basically what we already do ) - Declare syntax to "exclude" a potential collision from either composite part. Our only real difference at present is unlike these systems, we assume we can simply guess which one wins and just choose it automatically, where collision systems tend to force you to deal with the situation if any collision occurs. > I am also not very comfortable with our current state, because it has > a lot of uncertainty in terms of how the eclass phase functions are > called. > > My counter proposal to this is that we stop calling eclass phase > functions automatically, and to minimize the amount of boilerplating > we would have to do, we use a variable, such as ECLASS_PHASES which > would be defined at the ebuild level and contain a list of the eclass > phase functions we want to run automatically. > > Going back to my previous example, say your ebuild does the following: > > -- code begins here -- > > inherit foo bar > > # Foo and bar both have src_unpack and src_install functions. > # we want foo's src_unpack and bar's src_install: > > ECLASS_PHASES="foo_src_unpack > bar_src_install" > > -- code ends here --- > > If ECLASS_PHASES is undefined, I think the default should be to not run > the eclass phase functions. > > Yes, this means there is some boilerplating. However, there are some > strong advantages: > > - this is no longer dependent on order of inheritance. > - The ebuild author knows exactly which eclass phase functions will > be run. > > This proposal, seems reasonable, given my comments. I anticipate however its biggest downside would be the requirement to state *all* the functions you want, which would lead to maintenance headaches due to people forgetting to declare they wanted some function or other. 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. If baz provides no src_unpack, then the ebuild in question is simply left without one. You'll still need to declare src_unpack explicitly if you need use conditional behaviour, however. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
