Closed p5pRT closed 9 years ago
p5pRT
commented
9 years ago B is still using some PERL_VERSION checks in multiple places whereas it's part of core\, and I'm not aware of plans to remove it from core.
Removing dead code makes it simpler to read\, and for archeology git is a great tool.
p5pRT
commented
9 years ago p5pRT
commented
9 years ago On Mon Sep 14 11:10:32 2015\, atoomic@cpan.org wrote:
This is a bug report for perl from atoomic@cpan.org\, generated with the help of perlbug 1.40 running under perl 5.23.3.
----------------------------------------------------------------- [Please describe your issue here]
B is still using some PERL_VERSION checks in multiple places whereas it's part of core\, and I'm not aware of plans to remove it from core.
Removing dead code makes it simpler to read\, and for archeology git is a great tool.
Can you provide a patch?
Thank you very much.
-- James E Keenan (jkeenan@cpan.org)
p5pRT
commented
9 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
9 years ago James\, a patch was provided in my original message as an attached file
2015-09-14 17:19 GMT-06:00 James E Keenan via RT \perlbug\-followup@​perl\.org :
On Mon Sep 14 11:10:32 2015\, atoomic@cpan.org wrote:
This is a bug report for perl from atoomic@cpan.org\, generated with the help of perlbug 1.40 running under perl 5.23.3.
----------------------------------------------------------------- [Please describe your issue here]
B is still using some PERL_VERSION checks in multiple places whereas it's part of core\, and I'm not aware of plans to remove it from core.
Removing dead code makes it simpler to read\, and for archeology git is a great tool.
Can you provide a patch?
Thank you very much.
-- James E Keenan (jkeenan@cpan.org)
--- via perlbug: queue: perl5 status: new https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126058
p5pRT
commented
9 years ago On Mon Sep 14 17:07:41 2015\, atoomic@cpan.org wrote:
James\, a patch was provided in my original message as an attached file
https://rt-archive.perl.org/perl5/Ticket/Attachment/1365405/731807/0001-Remove- legacy-dead-code-from-B.patch
My error. All tests passing on ordinary Linux build. Comments from people familiar with B and with XS sought.
Thank you very much.
-- James E Keenan (jkeenan@cpan.org)
p5pRT
commented
9 years ago On Mon\, Sep 14\, 2015 at 11:10:33AM -0700\, Nicolas R. wrote:
B is still using some PERL_VERSION checks in multiple places whereas it's part of core\, and I'm not aware of plans to remove it from core.
Removing dead code makes it simpler to read\, and for archeology git is a great tool.
Well I think originally the intention was that that the same code base for B could be shared among the various maintenance releases\, but I think that's more or less dead now. It's too much work to maintain portability across releases\, and we tend to just point-patch maintenance release as when they need it.
So this gets my vote.
-- No man treats a motor car as foolishly as he treats another human being. When the car will not go\, he does not attribute its annoying behaviour to sin\, he does not say\, You are a wicked motorcar\, and I shall not give you any more petrol until you go. He attempts to find out what is wrong and set it right. -- Bertrand Russell\, Has Religion Made Useful Contributions to Civilization?
p5pRT
commented
9 years ago On Mon Sep 14 11:10:32 2015\, atoomic@cpan.org wrote:
B is still using some PERL_VERSION checks in multiple places whereas it's part of core\, and I'm not aware of plans to remove it from core.
Removing dead code makes it simpler to read\, and for archeology git is a great tool.
Thanks\, applied as 9ca4b7ea1df2a8085f1c9fc84c5c2a8eebc01f52.
Tony
p5pRT
commented
9 years ago @tonycoz - Status changed from 'open' to 'resolved'
p5pRT
commented
8 years ago On Sep 17\, 2015\, at 2:24 AM\, Tony Cook via RT \perlbug\-followup@​perl\.org wrote: On Mon Sep 14 11:10:32 2015\, atoomic@cpan.org wrote:
B is still using some PERL_VERSION checks in multiple places whereas it's part of core\, and I'm not aware of plans to remove it from core.
Removing dead code makes it simpler to read\, and for archeology git is a great tool.
Thanks\, applied as 9ca4b7ea1df2a8085f1c9fc84c5c2a8eebc01f52.
Oh my\, what have you done? You hereby added yourself to the list of people who made CPAN worse to maintain.
Please revert. This is useful information you cannot get anywhere else. p5p maintains not a single useful documentation about the versions of those structures.
The goal is to decrease entropy\, not making it worse.
p5pRT
commented
8 years ago Hi Reini\, I probably do not have enough deep perl knowledge to have a relevant answer\, but to my mind this seems a strange policy to do not remove dead code for documentation purpose in any software in general.
The main purpose behind this commit was to - provide a lighter code - easier for a newbie to understand it as a whole - easier to maintain
Maybe it's doing more hurt than benefits\, if so I just would like to understand.
Note\, that you can still access these informations from an older version/tag.
I can understand that you would like to know what was the previous behavior for an older version / what was the changes in that version.
But should not you use git to check changes from a previous version ? i.e.> git diff v5.21.0..v5.23.0 ext/B/B.xs
Are you complaining that this commit is going to make the diff more difficult to read ?
Are you asking to convert this to a pod ?
Could you describe some useful cases where having previous behaviors in the source code is helpful.
Maybe reverting this case is the correct thing to do\, but I'm just trying to understand the value of preserving dead code.
Thanks for your precisions. nicolas
On Thu Sep 17 07:02:58 2015\, reini.urban@gmail.com wrote:
On Sep 17\, 2015\, at 2:24 AM\, Tony Cook via RT \<perlbug- followup@perl.org> wrote: On Mon Sep 14 11:10:32 2015\, atoomic@cpan.org wrote:
B is still using some PERL_VERSION checks in multiple places whereas it's part of core\, and I'm not aware of plans to remove it from core.
Removing dead code makes it simpler to read\, and for archeology git is a great tool.
Thanks\, applied as 9ca4b7ea1df2a8085f1c9fc84c5c2a8eebc01f52.
Oh my\, what have you done? You hereby added yourself to the list of people who made CPAN worse to maintain.
Please revert. This is useful information you cannot get anywhere else. p5p maintains not a single useful documentation about the versions of those structures.
The goal is to decrease entropy\, not making it worse.
p5pRT
commented
8 years ago On Thu Sep 17 07:02:58 2015\, reini.urban@gmail.com wrote:
Please revert. This is useful information you cannot get anywhere else. p5p maintains not a single useful documentation about the versions of those structures. The git history seems sufficient to me. I don't follow what you're trying to achieve.
The goal is to decrease entropy\, not making it worse. I would argue that removal of dead code reduces entropy. Docs don't belong buried in code. If you feel this documentation is useful to someone\, I would argue it belongs in POD.
p5pRT
commented
8 years ago On Sep 17\, 2015 18:06\, "Todd Rinaldo via RT" \perlbug\-followup@​perl\.org wrote:
On Thu Sep 17 07:02:58 2015\, reini.urban@gmail.com wrote:
Please revert. This is useful information you cannot get anywhere else. p5p maintains not a single useful documentation about the versions of those structures. The git history seems sufficient to me. I don't follow what you're trying to achieve.
No\, it is not. What I want? As I said\, CPAN authors need boilerplate code the keep their modules running for all versions. They need the history of the op and sv changes.
p5p is not able to produce that\, not even talking about not being able to maintain B properly. It got better\, but still is a nightmare. You are actively helping to make it worse. Thanks. CPAN thanks you
The goal is to decrease entropy\, not making it worse. I would argue that removal of dead code reduces entropy. Docs don't belong buried in code. If you feel this documentation is useful to someone\, I would argue it belongs in POD.
I wrote several pods. Was it included? No. Go figure.
And here we need the necessary boilerplate for the type history\, which is now lost. There are several cpan modules which need that.
And please don't interfere with code you have no idea of.
p5pRT
commented
8 years ago On Sep 17\, 2015\, at 14:24\, Reini Urban \reini\.urban@​gmail\.com wrote:
On Sep 17\, 2015 18:06\, "Todd Rinaldo via RT" \perlbug\-followup@​perl\.org wrote:
On Thu Sep 17 07:02:58 2015\, reini.urban@gmail.com wrote:
Please revert. This is useful information you cannot get anywhere else. p5p maintains not a single useful documentation about the versions of those structures. The git history seems sufficient to me. I don't follow what you're trying to achieve.
No\, it is not. What I want? As I said\, CPAN authors need boilerplate code the keep their modules running for all versions. They need the history of the op and sv changes.
Inclusion isn't a guarantee of continued relevance or correctness.
To what extent is Perl obligated to include obsolete implementation?
To what extent is Perl obligated to maintain obsolete implementation?
To what extent is Perl obligated to assure the quality of obsolete implementation?
-- Rocco Caputo \rcaputo@​pobox\.com
p5pRT
commented
8 years ago On Thu Sep 17 11:24:49 2015\, reini.urban@gmail.com wrote:
On Sep 17\, 2015 18:06\, "Todd Rinaldo via RT" \perlbug\-followup@​perl\.org
The goal is to decrease entropy\, not making it worse. I would argue that removal of dead code reduces entropy. Docs don't belong buried in code. If you feel this documentation is useful to someone\, I would argue it belongs in POD.
I wrote several pods. Was it included? No. Go figure.
Can you point to an RT or a mailing list link where you submitted it? I for one would interested in helping it get in.
p5pRT
commented
8 years ago * Rocco Caputo \rcaputo@​pobox\.com [2015-09-17 21:00]:
Inclusion isn't a guarantee of continued relevance or correctness.
No\, but exclusion is a guarantee of the opposite.
To what extent is Perl obligated to include obsolete implementation?
To what extent is Perl obligated to maintain obsolete implementation?
To what extent is Perl obligated to assure the quality of obsolete implementation?
Please take http://neilb.org/tag/cpan-river/ to heart.
The questions you are asking amount to asking to what extent p5p is committed to causing downstream pain.
This must not be turned into a question of whether p5p can lawyer its way out of the fine print in some contract that p5p signed off on and is now bound by. That would be an adversarial stance toward its very users\, which really makes no sense.
There is no easy answer to the question\, primarily due to the fact that resources available to p5p are so utterly scarce. Some pain on some side is inevitable. Defensive lawyering is most plainly not a useful response though.
It should never be āsorry that you are in pain\, but note that I was not under any obligation not to cause itā.
It should always be āsorry that Iām about to cause some pain\, I tried my best but found no way of preventing (all of) itā.
Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>
p5pRT
commented
8 years ago * Reini Urban \reini\.urban@​gmail\.com [2015-09-17T10:02:34]
On Sep 17\, 2015\, at 2:24 AM\, Tony Cook via RT \perlbug\-followup@​perl\.org wrote: Thanks\, applied as 9ca4b7ea1df2a8085f1c9fc84c5c2a8eebc01f52.
Oh my\, what have you done? You hereby added yourself to the list of people who made CPAN worse to maintain.
No\, he has applied a commit that was proposed and seconded. You seem unhappy with that because you think it's a bad change. A more constructive reply might have bene just:
Please revert. This is useful information you cannot get anywhere else. p5p maintains not a single useful documentation about the versions of those structures.
There\, you make an argument for why it's a bad idea\, without insinuating that somewhere beyond the grave\, Richard Nixon is continuing work on his Enemies List. Except it's all Perl people this time.
nicolas's reply seems quite on point: he thinks he is improving the code's readability\, which he seems to be\, but acknowledges that what you're describing sounds useful\, too\, and might belong in a more purpose-built document. That seems reasonable\, too.
You said you wrote some documentation on point. Is it still useful? Could you provide a link?
There's no reason to throw out useful information\, but it should be encoded in a way that's easy to use\, rather than left as dead code for each programmer to work out on their own.
-- rjbs
p5pRT
commented
8 years ago On Sep 17\, 2015\, at 15:41\, Aristotle Pagaltzis \pagaltzis@​gmx\.de wrote:
* Rocco Caputo \rcaputo@​pobox\.com [2015-09-17 21:00]:
Inclusion isn't a guarantee of continued relevance or correctness.
No\, but exclusion is a guarantee of the opposite.
Dead code has already been proven irrelevant. It will eventually be incorrect unless someone continues to maintain and QA it. Therefore:
To what extent is Perl obligated to include obsolete implementation?
To what extent is Perl obligated to maintain obsolete implementation?
To what extent is Perl obligated to assure the quality of obsolete implementation?
The questions you are asking amount to asking to what extent p5p is committed to causing downstream pain.
No. The words you're trying to put in my mouth are inflammatory and inequivalent.
There seem to be strong ideological differences at play here. My questions probe these differences and prompt their discussion without trying to lead people to a particular conclusion.
The vast complex web of conflicts between Perl's development priorities and all of CPAN's is a given. The enligtening information is how people individually choose to reconcile those conflicts and what a consensus might be\, assuming anything resembling a consensus exists.
-- Rocco Caputo \rcaputo@​pobox\.com
p5pRT
commented
8 years ago * Rocco Caputo \rcaputo@​pobox\.com [2015-09-17 23:45]:
On Sep 17\, 2015\, at 15:41\, Aristotle Pagaltzis \pagaltzis@​gmx\.de wrote:
* Rocco Caputo \rcaputo@​pobox\.com [2015-09-17 21:00]:
Inclusion isn't a guarantee of continued relevance or correctness.
No\, but exclusion is a guarantee of the opposite.
Dead code has already been proven irrelevant. It will eventually be incorrect unless someone continues to maintain and QA it.
How will it become incorrect if itās for versions of Perl that are no longer being updated? How will it become irrelevant if the versions of Perl it is for continue to exist and continue to be developed against?
You simply state as fact that this will happen; Iām unconvinced without some reasoning why that should be so.
To what extent is Perl obligated to include obsolete implementation?
To what extent is Perl obligated to maintain obsolete implementation?
To what extent is Perl obligated to assure the quality of obsolete implementation?
The questions you are asking amount to asking to what extent p5p is committed to causing downstream pain.
No. The words you're trying to put in my mouth are inflammatory and inequivalent.
They may be so\, but they are not words I was trying to put in your mouth. I claimed that the things you said amount to this other thing I said; but I did not say nor meant to imply that *you* said the thing I drew an equivalence to.
Do you find it fair to characterise your questions as questions in the domain of contractual law?
(I must concede that this is not an open question: I cannot find a ānoā credible\, considering that the questions ask about the _obligations_ of Perl.)
(Who is āPerlā\, btw? The programming language incarnate does not existā¦ are you referring to p5p? Or some other group?)
There seem to be strong ideological differences at play here. My questions probe these differences and prompt their discussion without trying to lead people to a particular conclusion.
The vast complex web of conflicts between Perl's development priorities and all of CPAN's is a given. The enligtening information is how people individually choose to reconcile those conflicts and what a consensus might be\, assuming anything resembling a consensus exists.
Fair enough; I did read them as leading questions\, rather than take them simply as open ones. I still believe that theyāre the wrong mode of even looking at the problem\, per above\, but I agree that the issues you tried to probe (ultimately) are the ones we need to discuss.
Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>
p5pRT
commented
8 years ago On Sep 17\, 2015\, at 11:44 PM\, Rocco Caputo \rcaputo@​pobox\.com wrote:
On Sep 17\, 2015\, at 15:41\, Aristotle Pagaltzis \pagaltzis@​gmx\.de wrote: * Rocco Caputo \rcaputo@​pobox\.com [2015-09-17 21:00]:
Inclusion isn't a guarantee of continued relevance or correctness.
No\, but exclusion is a guarantee of the opposite.
Dead code has already been proven irrelevant. It will eventually be incorrect unless someone continues to maintain and QA it. Therefore:
This is not dead code. Now it it\, yes. This is/was boilerplate code for all B modules which have to work on OP and SV types. A simple cpan grep would have helped:
https://github.com/jbenjore/B-Utils/blob/master/Utils.xs#L44 https://github.com/rurban/perl-compiler/blob/master/C.xs#L45 https://github.com/rurban/b-generate/blob/master/Generate.xs#L73
just for the SV classes. And this is just from my local harddisc.
To what extent is Perl obligated to include obsolete implementation?
To what extent is Perl obligated to maintain obsolete implementation?
To what extent is Perl obligated to assure the quality of obsolete implementation?
The questions you are asking amount to asking to what extent p5p is committed to causing downstream pain.
No. The words you're trying to put in my mouth are inflammatory and inequivalent.
"Downstream pain" is not inflammatory and inequivalent.
It would be less pain it p5p would offer help to CPAN authors. But they are not.
There seem to be strong ideological differences at play here. My questions probe these differences and prompt their discussion without trying to lead people to a particular conclusion.
The vast complex web of conflicts between Perl's development priorities and all of CPAN's is a given. The enligtening information is how people individually choose to reconcile those conflicts and what a consensus might be\, assuming anything resembling a consensus exists.
p5pRT
commented
8 years ago On Sep 17\, 2015\, at 5:11 PM\, Atoomic via RT \perlbug\-followup@​perl\.org wrote:
Hi Reini\, I probably do not have enough deep perl knowledge to have a relevant answer\, but to my mind this seems a strange policy to do not remove dead code for documentation purpose in any software in general.
The main purpose behind this commit was to - provide a lighter code - easier for a newbie to understand it as a whole
No\, it is not. A newbie asks himself what types are valid. A newbie is not only interested in blead\, he is interested in perl. perl is not just blead\, even if blead thinks so of itself. If it needs to look good\, look at the documentation. code is technical information.
- easier to maintain
So let the maintainers decide. They did the work to help CPAN authors in the past. If you and Todd now interfere to please the lazy maintainers CPAN authors are punished. From my point of view some outsiders are arguing in favor of the lazy maintainers. You had nothing to do with the maintenance work at all\, and nothing to do with downstream neither.
This does not help perl and not CPAN.
Maybe it's doing more hurt than benefits\, if so I just would like to understand.
Note\, that you can still access these informations from an older version/tag.
Who does? This argumentation is not helpful and wrong. Everything is lost forever in the depths of svn or git\, and nothing was ever successfully resurrected when deleted with that kind of argumentation. The parrot jit was deleted with that kind of argumentation because someone was to lazy or incapable to fix 2 tiny lines for amd64. It is gone\, and thereās no chance to get it back. On the other hand the parrot optimizer could have been resurrected because nobody deleted it yet.
Deleting useful information is never good\, and calling it ādead codeā and "legacy" is harmful. Please refrain from doing so. Maintainers are very willing to follow then. And sooner or later the product will be dead. Yes\, it happened.
Are you asking to convert this to a pod?
I have this information in two very popular documentations. But documentation is not code. It is much more work to extract the necessary CPAN code from a doc than from code. And the internal docs Iām maintaining are usually half a year up to a year behind. I never took this code out of some docs\, I always took it out of code. code runs\, documentation is mostly wrong. perl5 does not even SW management to test their pod samples if they are right or broken. We did that with parrot\, but it was still broken all the time. Maintainers rarely care about docs. Outsiders bother them later.
Could you describe some useful cases where having previous behaviors in the source code is helpful.
See my answer of CPAN modules using these parts verbatim. Iām pretty sure thereās more\, that were just the 3 parts on my harddisc.
Anybody who wants to print parts of SVās needs it. B offers no API to do that\, and even if it will offer it in the future\, it will not help CPAN\, because they have to work on older perls also.
Maybe reverting this case is the correct thing to do\, but I'm just trying to understand the value of preserving dead code.
It is NOT DEAD CODE! It lives.
Thanks for your precisions. nicolas
On Thu Sep 17 07:02:58 2015\, reini.urban@gmail.com wrote:
On Sep 17\, 2015\, at 2:24 AM\, Tony Cook via RT \<perlbug- followup@perl.org> wrote: On Mon Sep 14 11:10:32 2015\, atoomic@cpan.org wrote:
B is still using some PERL_VERSION checks in multiple places whereas it's part of core\, and I'm not aware of plans to remove it from core.
Removing dead code makes it simpler to read\, and for archeology git is a great tool.
Thanks\, applied as 9ca4b7ea1df2a8085f1c9fc84c5c2a8eebc01f52.
Oh my\, what have you done? You hereby added yourself to the list of people who made CPAN worse to maintain.
Please revert. This is useful information you cannot get anywhere else. p5p maintains not a single useful documentation about the versions of those structures.
The goal is to decrease entropy\, not making it worse.
--- via perlbug: queue: perl5 status: resolved https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126058
p5pRT
commented
8 years ago On Sep 18\, 2015\, at 01:04\, Aristotle Pagaltzis \pagaltzis@​gmx\.de wrote:
* Rocco Caputo \rcaputo@​pobox\.com [2015-09-17 23:45]:
On Sep 17\, 2015\, at 15:41\, Aristotle Pagaltzis \pagaltzis@​gmx\.de wrote:
* Rocco Caputo \rcaputo@​pobox\.com [2015-09-17 21:00]:
Inclusion isn't a guarantee of continued relevance or correctness.
No\, but exclusion is a guarantee of the opposite.
Dead code has already been proven irrelevant. It will eventually be incorrect unless someone continues to maintain and QA it.
How will it become incorrect if itās for versions of Perl that are no longer being updated?
I've been talking about dead code the general sense. It seems like you're discussing something more specific. Any disagreement we may have may stem from us talking about different things.
If what defines correctness changes in an evolving project\, code that must remain correct with respect to the past may no longer be correct in the present. For example\, even dead code must continue to compile and link against new releases. If executed\, it must not fail in novel ways as the things it depends on change.
How will it become irrelevant if the versions of Perl it is for continue to exist and continue to be developed against?
Dead code is irrelevant to the current state of a project by definition[1]. Compiling it into new releases is pointless. Any vestigial value can be preserved by converting it to documentation\, an example program\, a third-party library\, or a comment.
-- Rocco Caputo \rcaputo@​pobox\.com [1] https://en.wikipedia.org/wiki/Dead_code
p5pRT
commented
8 years ago On Sat Sep 19 17:32:57 2015\, rcaputo wrote:
How will it become irrelevant if the versions of Perl it is for continue to exist and continue to be developed against?
Dead code is irrelevant to the current state of a project by definition[1]. Compiling it into new releases is pointless. Any vestigial value can be preserved by converting it to documentation\, an example program\, a third-party library\, or a comment.
So would you support a patch that drops support for all Perl versions except blead from Encode on CPAN since all perl except blead is "dead code" and why should Encode support it?
Should every comment with an RT number in blead be deleted since the bug is "dead code" since it doesnt exist anymore?
-- bulk88 ~ bulk88 at hotmail.com
p5pRT
commented
8 years ago * Rocco Caputo \rcaputo@​pobox\.com [2015-09-20 02:35]:
* Aristotle Pagaltzis \pagaltzis@​gmx\.de [2015-09-18 07:10]:
* Rocco Caputo \rcaputo@​pobox\.com [2015-09-17 23:45]:
Dead code has already been proven irrelevant. It will eventually be incorrect unless someone continues to maintain and QA it.
How will it become incorrect if itās for versions of Perl that are no longer being updated?
I've been talking about dead code the general sense. It seems like you're discussing something more specific. Any disagreement we may have may stem from us talking about different things.
It seems like Iām discussing something more specific?
Well we seem to be in the thread about perl#126058. Can you guess what specific thing I might be discussing?
If what defines correctness changes in an evolving project\, code that must remain correct with respect to the past may no longer be correct in the present. For example\, even dead code must continue to compile and link against new releases. If executed\, it must not fail in novel ways as the things it depends on change.
The question in perl#126058 is whether whatās being called dead code is even dead code in the first place. That was what my questions were about; since āI seem to be discussing something specificā you seem to have missed their thrust entirely and simply responded with a general discussion of the demerits of dead code. However correct the statements you made about dead code\, they have nothing to do with the question of whether the declared-dead code actually qualifies as such.
How will it become irrelevant if the versions of Perl it is for continue to exist and continue to be developed against?
Dead code is irrelevant to the current state of a project by definition[1]. Compiling it into new releases is pointless. Any vestigial value can be preserved by converting it to documentation\, an example program\, a third-party library\, or a comment.
That is all true. It is also irrelevant to the decisions about actual patches that need to be made in this ticket. Do you have any thoughts on that?
Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>
p5pRT
commented
8 years ago On Sep 21\, 2015\, at 04:36\, Aristotle Pagaltzis \pagaltzis@​gmx\.de wrote:
* Rocco Caputo \rcaputo@​pobox\.com [2015-09-20 02:35]:
* Aristotle Pagaltzis \pagaltzis@​gmx\.de [2015-09-18 07:10]:
* Rocco Caputo \rcaputo@​pobox\.com [2015-09-17 23:45]:
Dead code has already been proven irrelevant. It will eventually be incorrect unless someone continues to maintain and QA it.
How will it become incorrect if itās for versions of Perl that are no longer being updated?
I've been talking about dead code the general sense. It seems like you're discussing something more specific. Any disagreement we may have may stem from us talking about different things.
It seems like Iām discussing something more specific?
Well we seem to be in the thread about perl#126058. Can you guess what specific thing I might be discussing?
My side of this discussion has always been about dead code in general. I wanted to address the pattern of a recurring problem instead of the specifics of this instance.
When I recognized my answers to your question were obviously going to be beneath you\, it made me realize we weren't talking about the same thing. I wanted to point out that incongruity before it got out of hand. I seem to have made things worse by doing so. I suppose that's a form of progress.
I apologize for my intrusion. It's obviously unwelcome\, and it wasn't as helpful as I imagined.
-- Rocco Caputo \rcaputo@​pobox\.com
p5pRT
commented
8 years ago * bulk88 via RT \perlbug\-followup@​perl\.org [2015-09-21T02:48:31]
On Sat Sep 19 17:32:57 2015\, rcaputo wrote:
Dead code is irrelevant to the current state of a project by definition[1]. Compiling it into new releases is pointless. Any vestigial value can be preserved by converting it to documentation\, an example program\, a third-party library\, or a comment.
So would you support a patch that drops support for all Perl versions except blead from Encode on CPAN since all perl except blead is "dead code" and why should Encode support it?
Should every comment with an RT number in blead be deleted since the bug is "dead code" since it doesnt exist anymore?
This is a false analogy.
Encode is released in a way that makes it possible to install on older perls. B is not.
If you can't install B on perl 5.12\, because B updates only come in new versions of Perl\, then keeping code in B to support 5.12 is not useful. It will not be reached\, so the code is dead.
The value that Reini initially pointed out was that someone who wants to target an older version of perl could look at the B source and see how things changed over time. This is value\, but it has nothing to do with the code still being executed.
Your analogy to Encode is really far off the mark.
-- rjbs
Migrated from rt.perl.org#126058 (status was 'resolved')
Searchable as RT126058$