Front page | perl.perl5.porters |
Postings from November 2011
> From: Shlomi Fish > On Fri, 25 Nov 2011 19:02:46 +0100 "Konovalov, Vadim" wrote: > > > From: Shlomi Fish [mailto:shlomif@shlomifish.org] > > > "Konovalov, Vadim wrote: > > > > > From: Jesse Vincent [mailto:jesse@fsck.com] > > > > > On Fri, Nov 25, 2011 at 02:49:15PM +0200, Shlomi Fish wrote: > > > > > > I'm issuing this "request-for-comments" to see if anyone > > > > > can see a good reason > > > > > > why I (or someone else who volunteers to do that) > > > should not convert > > > > > > "lib/perl5db.pl" (which implements "perl -d") to > "use strict;" > > > > > > and "use warnings;"? If everyone is OK with that, then I'd > > > > > like to try doing > > > > > > exactly that. > > > > > > > > > > I'd love to see it happen. > > > > > > > > Bad idea. > > > > > > > > What exactly benefits are? > > > > > > The same benefits of having "strict" and "warnings" in any > > > code: less potential > > > bugs, introducing less bugs in the future, etc. > > > > this logic does not work here, because perl5db.pl is not "any code". > > Due to specifics of perl debugger interface. > > > > I see a very special beauty of having all implemented in a single > > file having some 322,595 bytes in size. > > > > Well, adding "use strict;" and "use warnings;" will keep it > as a single file. fine. this is something :) > > > Adding modularity there will bring us forest of unneeded > files and then > > introduce bugs. > > > > Once again: perl5db is some highly efficient implemented internals > > that is not "any code" starving for "use strict" > > > > "use strict;" can really help in the future. it will drive debugger into another file suddenly. Don't you afraid of this? Have you thought about clobbering proper internal debugger variables if someting will happen inside "strict.pm" file? > > > > > > > > What is bad in a strategy "don't fix things unless they > are broken" > > > > > > > > > > See: > > > > > > * > > > http://szabgab.com/what-does--if-it-aint-broke-dont-fix-it--re > > > ally-mean.html > > > > I browsed it and I do not buy it. Sorry. > > There is some idea there, but not at all true. IMHO. > > > > Why do you feel it isn't true? mostly the same reasons: I. if you're introducing new cosmetic changes (modernizing) without really understanding on what is going underneath - there are chances to introduce a breackage. ok, there is a sentence - "I think people who say that sentence are afraid that the new version will break something. Sure there is always a chance that a change introduces an error but if we are afraid to touch the code what will happen when later on we encounter a case where it does not work?" perl5db.pl is an extremely efficient and throughout-thought code, with different magic happening at different levels. It is very well working because there are debuggers based on it and they're working good, read "ptkdb" to get an idea by blindly modernizing it you're in chance to adjust this logic, because you do not understand all internals. Please notice - adding "use strict" without actually understanding internal mechanics - is what I am afraid. Your argumentation at http://szabgab.com/what-does--if-it-aint-broke-dont-fix-it--really-mean.html states that it is better to change and face an error earlier, rather than in tight working environment. I am stating that changing without understanding deep internals first - this is wrong. IOW you're asking for trouble. This is why I am proposing to seek for simplier module to add "use strict;" to. II. there should be better reasons on changes, than cosmetics onces, and this is another point of my disagreement. so, there are two, > > > > > > * http://shlomif-tech.livejournal.com/37969.html > > > > OMG. tl;dr :) :) > > > > "Too long; didn't read?"? Seriously? It's not that long, and > reading all the > perl5-porters in a month is much more time-consuming. If you > didn't bother > reading that, what should make me think that you would bother > reading the next > version of my RFC which you think I should write? original RFC was too short and didn't contained any serious reasoning why the change worth the hassle. Its incompletness should be clear after the comments I made. You could choose not to write better one, but - my statement is - original one is bogus, I haven't saw better one, but I have no promise on reading larger one, as you probably do not have a promice on writing better one. we're on par here :) But remember - you wrote "if any one has any ideas against" I have a whole bunch of these. :) Ok, I promise to fix my last tl'dr; later today :) Regards, Vadim.Thread Previous | Thread Next