[gentoo-dev] Re: [PATCH FIXED] Introduce edefault() as a friendly default sub-phase wrapper.
On Sat, May 11, 2013 at 5:30 AM, Michał Górny mgo...@gentoo.org wrote: Fixed naming the proper default sub-phase and declaring 'edefault' in python_prepare_all(). --- I think I prefer to explicitly name the function I want to call, so I don't really see any great benefit here. I'm not strongly opposed to it, but I don't see myself using it either. Also, how would this interact with other eclasses which may define a similar edefault function? Packages using distutils-r1 don't often utilize other phase-happy eclasses, but I'm sure it will happen eventually.
Re: [gentoo-dev] Re: [PATCH FIXED] Introduce edefault() as a friendly default sub-phase wrapper.
On Sat, 11 May 2013 11:51:39 -0400 Mike Gilbert flop...@gentoo.org wrote: On Sat, May 11, 2013 at 5:30 AM, Michał Górny mgo...@gentoo.org wrote: Fixed naming the proper default sub-phase and declaring 'edefault' in python_prepare_all(). --- I think I prefer to explicitly name the function I want to call, so I don't really see any great benefit here. I'm not strongly opposed to it, but I don't see myself using it either. Also, how would this interact with other eclasses which may define a similar edefault function? Packages using distutils-r1 don't often utilize other phase-happy eclasses, but I'm sure it will happen eventually. Well, the idea is that 'edefault' is defined by the eclass inventing the particular sub-phase. So if sub-phase A calls sub-phase B indirectly (trough the eclass and so on), edefault points to B eventually. Other thing would be, that after returning to A edefault will be no longer defined. That's fixable though, if ever needed. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PATCH FIXED] Introduce edefault() as a friendly default sub-phase wrapper.
On Sat, 11 May 2013 11:51:39 -0400 Mike Gilbert flop...@gentoo.org wrote: On Sat, May 11, 2013 at 5:30 AM, Michał Górny mgo...@gentoo.org wrote: Fixed naming the proper default sub-phase and declaring 'edefault' in python_prepare_all(). --- I think I prefer to explicitly name the function I want to call, so I don't really see any great benefit here. I'm not strongly opposed to it, but I don't see myself using it either. Same here for the reason you mention below. Long term I expect it to be more of a hassle than typing a few additional letters now. Also, how would this interact with other eclasses which may define a similar edefault function? Packages using distutils-r1 don't often utilize other phase-happy eclasses, but I'm sure it will happen eventually.
