Front page | perl.perl5.porters |
Postings from May 2011
> From: Aristotle Pagaltzis > * Joshua ben Jore <twists@gmail.com> [2011-05-26 20:20]: > > On Thu, May 26, 2011 at 1:26 AM, Jan Dubois > <jand@activestate.com> wrote: > > >On Wed, 25 May 2011, Joshua ben Jore wrote: > > >>On Wed, Apr 13, 2011 at 12:48 PM, Jan Dubois > <jand@activestate.com> wrote: > > >>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. > > > > 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. > > That’s just how the current messy, untenable situation came about. well, if we're measuring dence of messiness or untentable-o-meter in perl distribution, then "store_cop_label" is far from being most annoying, IMO. Its usage is small and limited, and is controlled over few lines, unlike other perl code - take PerlIO or whatever. there are inconsistencies over the years of much more weight. Maybe I am not understanding well your point of view (due to me being non-English speaker) If this is due to my mis-understanding of your saying, please correct me, I am lost. Vadim.Thread Previous | Thread Next