in reply to Re^2: Curious: are anon-hashes in random order? (updated)
in thread Curious: are anon-hashes in random order?

Hi perl-diddler,

So how could it cause confusion?

You as the author may be able to keep track of the keywords vs. subs, and Perl may be able to resolve the ambiguity most of the time, but it's not too difficult to accidentally cross the line where Perl may pick the wrong definition (for example, there's the warning "Ambiguous call resolved as CORE::continue(), qualify as such or use & at ..."). Also, another reader of your code (including a future maintainer - or even your future self) could easily become confused between next and &next, etc.

It's just one of those cases where as long as you know what you are doing and your script isn't intended for distribution then it's probably fine; but if you do intend the code for a wider audience then I was just pointing out that there are some good rules of thumb / conventions, such as not to define subs with the same name as Perl builtins unless you intend to replace them, and that constant names are typically uppercased.

Regards,
-- Hauke D

Replies are listed 'Best First'.
Re^4: Curious: are anon-hashes in random order? (updated)
by perl-diddler (Chaplain) on Sep 15, 2016 at 02:10 UTC
    Well, in this case, the code had been in a loop. The loop got large, so moved contents out, but then the loop control words no longer worked. In this case, the loop control words made it clear the derived sub, where the code in the main loop would go next. I used those constants (and have done similar in the past) for exactly those reasons -- even though the loop contents were no longer "inline", due to the use of such constants to indicate what they did in their previous loop the code was actually easier to understand -- more clear.

    If I had come up with a new or different set of constants, I don't think it would have been as clear. As for constants being upcased? That's so 80's. :-) Seriously -- all caps hurt my eyes and fingers typing -- I'll usually capitalize something, but there are many cases where doing so hurts perception and understanding.

    An example would be several math constants (displaying these on pm in code blocks, is bugged, so you'll have to use your imagination a bit: ( But the 3 chars are Φ (Phi), ɸ (phi) and π (pi) ).

    sub Phi () { .5 * (5.**.5 - 1) } sub Φ () { goto &Phi } sub phi () { .5 * (1. + 5.**.5) } sub ɸ () { goto &phi } sub pi () { 4 * atan2(1, 1) } sub π () { goto &pi }
    If you upper-cased these, how would you tell Phi from phi. In the greek names (on the right which display as characters on modern systems), they are also the upper and lower case version of the greek phi. Pi, uses a lower case 'pi' just as it is in the english text version.

    Anyway, it's all about context... ;-)...