> From: Joshua ben Jore > On Thu, May 26, 2011 at 1:26 AM, Jan Dubois wrote: > > On Wed, 25 May 2011, Joshua ben Jore wrote: > >> On Wed, Apr 13, 2011 at 12:48 PM, Jan Dubois wrote: > >>> B::C is not in ext/ inside the core, so "EX" does not > apply. If you > >>> want to use it from CPAN, is has to be "A". From the core point of > >>> view, nothing on CPAN is "more special" than everything else. > >>> > >>> Claiming upfront that you intend to ignore the spirit of the rules > >>> anyways just makes it so much harder to get your patch > accepted, so > >>> please don't do that! > >> > >> There's utility in exposing things but not making promises about > >> stable APIs. If that's the point to this change, then I > find sympathy > >> with it. > > > > I'm not sure what you are arguing for here: > > > > b) ALL internal non-static functions should be exported in case some > > module finds utility in them. But unless the function is marked > > as part of the public API we reserve the right to change at will. Fine. I think all difficulties are settled now, and the patch could be applied now? I do not understand this long long waiting for a patch to be accepted. It fixes a breakage. It should be accepted. Speculating and finding reasons of not to accept it seems counterproductive to me > > I tend to think Reini ought to be able to get his internal non-static > function exported because he has actual utility in it. It isn't part > of the public supported API so it doesn't have any promises about > being stable between patch releases. We absolutely shouldn't > prematurely document and fix it's behavior into stability but there's > little point to preventing something useful from getting access to it. I agree, the only think I want to correct a little - it is not Reini who decided to use said function - it was rather consequences of development of perl parser, which happen to use it starting from some moment, and this should be fixed for B::C module. Vadim.Thread Previous | Thread Next