develooper Front page | perl.perl5.porters | Postings from May 2011

RE: [PATCH] export store_cop_label

Thread Previous | Thread Next
May 27, 2011 16:20
RE: [PATCH] export store_cop_label
Message ID:
> From: Aristotle Pagaltzis 
> * Joshua ben Jore <> [2011-05-26 20:20]:
> > 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:
> > >>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.

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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About