develooper Front page | perl.perl5.porters | Postings from July 2018

Re: [perl #132142] Bleadperl v5.27.3-34-gf6107ca24b breaksMLEHMANN/AnyEvent-HTTP-2.23.tar.gz

Thread Previous | Thread Next
Andreas Koenig
July 14, 2018 11:03
Re: [perl #132142] Bleadperl v5.27.3-34-gf6107ca24b breaksMLEHMANN/AnyEvent-HTTP-2.23.tar.gz
Message ID:
>>>>> On Sat, 14 Jul 2018 01:47:25 -0700, "Dave Mitchell via RT" <> said:

  > On Sat, Jul 14, 2018 at 10:15:11AM +0200, Andreas Koenig wrote:
 >> I would argue that
 >> - by having the documentation in the delta manpage,

  > There was no such documentation in perldelta. There was mention of a new
  > optimisation, not of a new sort language feature.

I have cited and llinked to the original places which sentences I speak
about and I maintain that one could read it differently.

  > There is a strong ethos within core development that new optimisations
  > shouldn't change user-visible behaviour where possible. If they do,
  > that's usually considered a bug, or if the trade off is worth it,
  > something to be documented as a gotcha.

It was not noticed for 13 years.

  > Note also that the change was back-ported to 5.8.4 - an odd thing to do
  > for a changed language feature.

I'll cite my timeline again from my previous posting:

2004-02-20: Within same RT ticket From: Dave Mitchell Citation: "I've now applied change #22349 to bleed, which makes @a = sort @a act inplace." 

And one line from man perlhist:

                 5.8.4         2004-Apr-21

For my reading, this is not a backport, it was properly injected into
blead between 5.8.3 and 5.8.4.

 >> - not taking it over into the perfunc/sort manpage and

  > There was nothing to take over.

 >> - not noticing the missing part of the documentation for 13 years

  > There was nothing missing.

 >> there is a case of a customary right on the side of all users of the
 >> language to keep the behaviour as implemented.

  > So do you agree that the behaviour which has been present since 5.000 and
  > was accidentally changed in 5.8.4, should be reverted to the 5.000 state,
  > since users have an expectation that the implemented behaviour should be
  > kept?

The changes in RT ticket 25263 got applause for 13 years. I have no
reason to doubt the achievement that came with it. Compare that with the
time between Ilmari's patch and the BBC ticket: 22 days.

 >> Alternatives have not been suggested yet and might exist that might lead
 >> to an even better solution for all parties.

  > I'm open to suggestions.

First of all I would suggest to document existing behaviour for v5.8.4 -
v5.28 and write tests that make sure we have it covered this time
around. In a second iteration I would hope somebody (hopefully with
decent language designing capabilities) comes up with something that
allows future users to choose which behaviour they want.

 >> > PS - I don't think for one minute the use of the phrase "in-place" was
 >> > ambiguous *in context*, in either the p5p discussion or the perldelta; it
 >> > was only ambiguous in the sense that your specific questions about it
 >> > provided no context as to what behaviour was being referring to.
 >> I'm not sure I can parse this sentence correctly. I think I have
 >> provided quite some context. If you think otherwise, feel free to ask.

  > You asked me some questions about the meaning of 'in-place'. I pointed
  > out the that phrase could potentially have two meanings, and
  > I wasn't clear which meaning you were referring to, so I gave answers
  > for both meanings. I further pointed out that where that phrase had been
  > used in perldelta / p5p discussion, I thought it was clear from the
  > context, which meaning was intended there - I wasn't conceding that
  > perldelta was ambiguous.



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