Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I mean, I use "HASH(0x1731300)HASH(0x174c918)" all the time.

    I think I saw it on the fourth read-through.

    If not a syntax error, at least a warning.

    -- dagolden

    • I agree with Schern that it should be a warning, not a fatal error (I don't think it could be a syntax error since we don't know what's in those scalars at compile time).

      A run time error would be bad for all the reasons Schern mentioned, but specifically because we all have debugging or logging code that does this. String interpolation shouldn't cause a run-time error. But since I've been bitten by this before I'm all in favor of it being a warning!

      • I was thinking that the concatenation would be the warning, not the interpolation.

        • But the concat is just one example of this problem isn't it? What about trying to use the wrong point in a nested data structure in a string? I've often used some 1 element array ref as a string because I missed something in some module's API.

    • Personally, I think that this is an example of something which should be another type of compile time error, which we don't have: semantic error. Specifically, the language technically allows it, but it has meaning that nobody would ever conceivably want.

      As I understand that what I can conceive is limited, I'd probably add a runtime option to perl to disregard semantic errors. However, without that option, I'd have it complain about interpolating the literal hash and exit immediately.

    • As soon as I say Dominus' email, I started thinking that it shouldn't apply to blessed objects due to overloading, but I see that Schwern already raised that case.

      Still, other than that, I could see a warning or a new 'strict' type being added in future versions of Perl.

  • I admit I didn't see it at first. So I copied the code into emacs. I have a habit of using perltidy in emacs to clean up my code, So I did that first. The problem jumped right out at me because of the indentation.

    Then I tried just using cperl-mode indenting and it pointed the problem out to me also.

    So does it really need to be a error/warning? or should we rely on our editor to find it.

    • I argue in my roles talk (well, the one I'm giving in Lisbon) that complexity management tools should be pushed into the langauge (when possible), rather than relying on external tools. While I don't think this falls in the category of complexity management, I think that the principle of "language support, when possible" applies here. If someone doesn't have your editor setup, they could easily miss this. Personally, I think this problem is common enough that a warning is quite appropriate.

      I still rememb

  • You could easily pull it off with an error match. I have a few of those on my after\ftplugin\javascript.vim, for guarding against things like trailing commas and whatnot. Here's mine:

    match Error /,\_s*[)\]}]\|[:,][^ ]\|\\|\\|[^0]\.[0-9]\+\|=\@!===\@!\|!==\@!/
    --
    --fREW
    http://blog.afoolishmanifesto.com
  • In a way, it's nice that everything can be converted to a string, but at least without something like autobox [cpan.org] combined with overload [cpan.org], where you can have control what it converts into (at least, I hope that will do the trick), it's generally not very useful.