Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • One reason why RHN-the-lesser raises the hackles of many a Perl hacker is because we already have RHN built into the language.

    At the heart of it all, Perl has only five types that matter: scalars, arrays, hashes, filehandles and coderefs. (Yes, I skipped two. If you know what they are, you know why I skipped them. ;-) Yes, there are tied variables, but what matters about them is not how their internals differ, but how they automagically hide those internals. And objects are another kettle of fish, but at the heart of it all, an object is a single piece of saved state that you sling about in your code, so it makes sense that it's a scalar value.

    It's sad that filehandles don't have a sigil, but them's the breaks. At least now we can do away with filehandles as a magic kind of variable and use file handle references instead.

    So when you see code like this:

    $a = $b + $c;
    $d += $e;
    $f = "$g$h$i" . $j;
    you know everything is right in the world. When you see something like this, on the other hand,
    $a = @b;
    @c = $d;
    you know something is amiss. Until you hit the error trap just below your conscious mind that reminds you what is special about assigning an array to a scalar, or a scalar to an array. Or a hash to a list, or a list to a hash. And so on.

    I haven't hacked in Perl6 yet, so I can't say for sure whether changing the syntax like so:

    $a = @b[5];  ## was $b[5]
    $c = %d{8};  ## was $d{8}
    will ultimately have a positive or negative impact. We all think we'll be better off, and the early reports confirm that, but it'll be a couple of years before we know for sure. My hunch is that Larry is right, and changing the syntax is the right thing to do, because it meshes well with how we think about our Perl code in the 21st Century, not in 1988.

    But it doesn't break the fundemental RHN-ness of sigils.

    • The sigil is only half the battle. Joel's article has a great example of pulling in unsafe data from a Web form. Perl's taint mode aside, we can't always know when it's safe to use a variable. When I was coding CGI apps, I did something like this:

      my $_name = $cgi->param('name'); my ($name) = $_name =~ /($untainting_regex)/;

      In this case, the sigil tells me nothing about whether or not it's safe to use that variable. If everything untaints, I can shove that data in the database. If it doesn't, I h

      • Crud, I hit 'Submit' instead of 'Preview'. Damn. Someone needs to read The Design of Everyday Things []. (Including me, to be fair.)

      • In this case, the sigil tells me nothing about whether or not it's safe to use that variable.

        Right. Because Perl embeds RHN-the-lesser (the kind of stuff in Petzold's book and the Windows API). The entire point of RHN-as-intended is to use common prefixes and principles of composition to describe the meaning of a variable: taintedness, Primality, object behavior, worksafe content, etc.

        The one huge problem with "Reverse Hungarian Notation", as Joel says, is that virtually everyone thinks RHN is RH