23:49 < Betelgeuse> zmedico: default calls the Portage implementation right? Is there a way to call the one exported by eclasses? 23:49 < zmedico> what's up? 23:49 < zmedico> you have to know the eclass name 23:49 < zmedico> so you can call $ECLASS_phase 23:49 < Betelgeuse> Yeah but I would not having to 23:50 < zmedico> can add that in the next EAPI :) So I propose we add eclass_default in the next EAPI.
I don't get it. Which eclass's function would it call?
(In reply to comment #1) > I don't get it. Which eclass's function would it call? > The one that would get used if the eclass did not define one.
(In reply to comment #2) > (In reply to comment #1) > > I don't get it. Which eclass's function would it call? > > > > The one that would get used if the eclass did not define one. > s/eclass/ebuild/ Basically if I inherit a b c and all of them export src_compile I want to be able to call c_src_compile in the src_compile of my ebuild by not having to know which one of the eclasses was the one exporting it.
I'd rather name it like 'next' and do a nice inheritance chain. It would be great if it could support three cases: 1) ebuilds calling their inherited eclasses: inherit cmake-utils src_install() { cmake-utils_src_install doinitd foo } where 'cmake-utils_src_install' would be replaced by simply 'next'. 2) eclasses calling their inherited eclasses; 3) (optionally) eclasses 'prepending' phases: git-2_src_unpack() { ... next # e.g. to default or another VCS } Of course, that would have to take a few assumptions: 1) ordering eclasses by inheritance -- every re-inherited eclass (along with its inherited eclasses) is moved to the end of inheritance chain, so we're clear which phases should go; and we don't want to call the same phase func twice in a 'next' chain, 2) possibly 'next' should localize its iterations so it can be called multiple times.
let's avoid obtuse names when they aren't necessary. "eclass_next" is much more clear and doesn't impose any more overhead.
What problem would this solve, actually? At the moment, ebuilds do this: inherit foo bar src_install() { bar_src_install <do some other things> } and with the change they would do: inherit foo bar src_install() { eclass_default # or next or eclass_next <do some other things> } In the first example the reader immediately sees what function is called, while in the second example he must look up eclass order in the inherit line. Plus, if someone would reorder eclasses there, it would have the side effect that another function is called, in spite of the ebuild having an explicit phase function. Seems to me that this is more error prone. In any case, no progress since 10 years. Closing.
