Currently eclass functions are only called once and the last eclass in inherit is preferred. For for example Java eclasses java-pkg-2_pkg_setup setup will always need to be called or else the ebuild will fail when it needs VM switching. For this reason I propose a similar scheme to EXPORT_FUNCTIONS but those functions would always be called even if the ebuild providers implementations for them. 3:06 <@vapier> Betelgeuse: said functionality would be nice ... "ALWAYS_CALL" is a crappy name though :p
Why is this necessary? Why not just ensure that ebuilds use eclasses the way said eclasses are supposed to be used?
(In reply to comment #1) > Why is this necessary? Why not just ensure that ebuilds use eclasses the way > said eclasses are supposed to be used? > People make mistakes.
(In reply to comment #2) > (In reply to comment #1) > > Why is this necessary? Why not just ensure that ebuilds use eclasses the way > > said eclasses are supposed to be used? > > People make mistakes. Sure, which is why we do testing. The problem with this approach is that when looking at a function defined in an ebuild, it's entirely unobvious that that function will do other things.
(In reply to comment #3) > > Sure, which is why we do testing. The problem with this approach is that when > looking at a function defined in an ebuild, it's entirely unobvious that that > function will do other things. > It's not really easy to know what's going on now either when you inherit multiple eclasses without investing all the eclasses on what they export.
The point is, currently when you look at a function, it does what that function says unless that function is overridden. This is consistent with well established language design principles. What you're proposing is completely at odds with this -- no longer will a function be implemented in a single place. Rather, it will be a horrible mishmash of code from arbitrary locations similar to the widely criticised AOP paradigm. It's well known that 'goto' is harmful, but this is worse -- it's a 'comefrom'. If the only use case for this is catching developer screwups, a better solution would be allowing eclasses to specify contract-style requirements. This would allow a larger category of mistakes to be caught, and doesn't have the associated ick factor.
(In reply to comment #5) > The point is, currently when you look at a function, it does what that function > says unless that function is overridden. This is consistent with well > established language design principles. What you're proposing is completely at > odds with this -- no longer will a function be implemented in a single place. > Rather, it will be a horrible mishmash of code from arbitrary locations similar > to the widely criticised AOP paradigm. It's well known that 'goto' is harmful, > but this is worse -- it's a 'comefrom'. > Well what I want could also be implemented as phases that can never be defined in ebuilds which should fit your statement above. It would basically be like making the hooks java eclasses used official and only usable in eclasses.
The same mechanism could work to stack hooks found in multiple profile.bashrc.
The interface could look something like this: add_phase_hook before pkg_setup $ECLASS_pre_pkg_setup Portage has related register_die_hook and register_success_hook functions that might also be useful as EAPI additions.
To be honest, I don't really like the concept of introducing something that does something with no ability of disabling or overriding it. And if we make it possible, we kinda get back to square one, just the other way around. For your use case, what if java is optional? Assuming that normally you'd do: use java && java-pkg-2_pkg_setup With your proposed solution it will no longer be possible. If you really want this, you have to have a stronger use case.
Unlikely to get done right, no reply to basic issues for over a year. Closing as WONTFIX.
(In reply to Michał Górny from comment #9) > To be honest, I don't really like the concept of introducing something that > does something with no ability of disabling or overriding it. Maybe something like python's "super" would be more appropriate. That way, when you implement a phase function, you get to decide whether or not you want to call super.
