Front page | perl.perl5.porters |
Postings from July 2017
On Wednesday 12 July 2017 23:44:39 H. Merijn Brand via RT wrote: > On Wed, 12 Jul 2017 22:53:57 -0600, Karl Williamson > <public@khwilliamson.com> wrote: > > > It came about not because of AvFILL, but because of the already-existing > > synonym, the evilly named "av_len". This name implies it gives a > > length, but in fact it is one-off from that. av_top_index, though > > cumbersome, accurately indicates what it returns. > > The problem with av_top_index is that it hat not (yet) been ported to > Devel::PPPort, Devel::PPPort is probably unmaintained... It has open couple of bugs since 2015 without any comments. And also pull requests are not processed since 2016. Even those security released like this: https://github.com/mhx/Devel-PPPort/pull/47 Because of those problems, I have no motivation to prepare any other patch for Devel::PPPort. For dead/unmaintained modules it is useless. > so I cannot change any XS code that uses av_len into > using the new function if that XS is to support 5.16.0 or older > > $ ack av_top_index > ppport.h > 1225:av_top_index||5.017009| > $ > > I know I didn't quote all of your message and I understand your > motivation, but the problem for these misnamed functions is much wider > than the scope of av_top_index, which is *only* available to XS, and XS > is more or less easy to fix by adding stuff to Devel::PPPort > > For the utf8 functions, the scope is WAY wider: it is used from > pure-perl, and renaming them (with or without aliases) would cause > major brain damage for all authors that use these functions (correct or > incorrect) when their code has to work on a wide range of perl versions. > > To be honest, I do not see an easy way out of that dilemma. If you have > one, I'm open to change for the better. Problem is that people very often use construct which I wrote in first comment. Or they read "is_utf8" means string is UTF-8 encoded and therefore I need to call utf8::decode() on it. And all this happens just because of wrong name from which can be deduced by more people what it should do -- which involves in *no* reading documentation... If we would not add better aliases, then broken code would be still produced on cpan. As utf8::is_utf8() is not needed too often, backward compatibility can be achieved by: *NEW_NAME = *utf8::is_utf8; I think this is a good compromise. If you think that upgrade and downgrade function names are fine, OK, but at least please add better name for is_utf8(). In original email I suggested is_upgraded(), so name would be bound with "upgrade()" function. Because it really checks if upgrade() was called or not.Thread Previous | Thread Next