in reply to Code cleanup; how best to deal with: defined(%hash) is deprecated at...

Add "use diagnostics;" to the top of your script and run it again. You'll see a more thorough explanation, including this:

Although defined %hash is false on a plain not-yet-used hash, it becomes true in several non-obvious circumstances, including iterators, weak references, stash names, even remaining true after undef %hash. These things make defined %hash fairly useless in practice. If a check for non-empty is what you wanted then just put it in boolean context (see "Scalar values" in perldata): 

    
        if (%hash) {
           # not empty
        }

[download]

There's not much I can add to that, other than to say that by following the advice above you may actually be removing an undiscovered bug.


Dave

Replies are listed 'Best First'.
Re^2: Code cleanup; how best to deal with: defined(%hash) is deprecated at...
by taint (Chaplain) on May 22, 2014 at 04:13 UTC
    Thanks davido.

    Darn good advice, and so obvious too. :) I hate it when I overlook the obvious. It's so embarrassing. :P

    I'll investigate with diagnostics.

    Actually. They're pretty much true|false booleans. That I use to determine the chosen positions of the "blocks" in the layout. So I'm fairly confident that the whole thing won't explode, or anything. But just the same; thought it worth asking. Before a final commitment.

    Thanks again, davido. For taking the time to reply

    --Chris

    ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

[reply]
      Try to remove defined and run your tests. If everything passes, you are probably safe.
      لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
[reply]

      The only final commitment ought to be $ git merge bool_hash. Until then it's pretty easy to git branch -D bool_hash

      Even if you've merged, you can still rewind without causing grief, as long as you haven't pushed somewhere where others might suffer. I know not everyone's sold on version control tools, but I find them empowering; I can try things without having to remember every change I made along the way. And if a plan comes together, I can merge. If not, cut off the experimental branch with the confidence of knowing that the stable branch is still untouched.

      If your project hasn't been using VC, it's not too late to start. Assuming it's currently in a working state, initialize a repo, create a "refactoring" branch (probably use a more descriptive name), and get to work. At each major decision, branch, then if it works well, merge.


      Dave

[reply]
[d/l]
[select]
        Hello, davido.

        Good advice. I hope anyone examining this thread, takes your advice to heart. No matter Git, SVN, CVS. Whatever your RCS, VCS. In the end you'll be glad you did -- really. :)

        As for this small endeavor; I already had the whole of the project open in my editor. I think ~90 files. So if anything went south. It was a simple matter of CTRL+Z to back out. :). But as a rule, version tracking/control is my motto.

        In the end, I took Perl's advice (also echoed by others in this thread), and simply removed the defined. That along with your thoughtful "wake-up call" regarding diagnostics, and a few tests, indicated it's all good now -- well that much, anyway.

        Thanks for all your input, davido.
        Much appreciated.

        --Chris

        ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

[reply]

In Section Seekers of Perl Wisdom