http://qs321.pair.com?node_id=438532


in reply to Should chomping a constant always raise an error?

Yours is a subtle question of typing. Possibly you are only talking about chomp because being a builtin the error is found at compile time; my_chomp won't be caught until runtime.

I agree with BigLug, it makes sense to complain for finding problems sooner. But this merely indicates that I accept the conventions surrounding const'ness. I don't want to change because the earliest finding of illogical actions in my code makes for easier coding in my view.

The view you consider, that const'ness be a protection given to a variable, seems less useful. If you wish to play with your idea further here is an imp (I think this is a bad idea as the resulting code seems misleading):

#!/usr/bin/perl use strict; use warnings; package protected; # constant data that doesn't complain, just doesn't change. # We could have a flag to allow a protected to store a value once; # We could have a "new" subroutine to hide the tied'ness. # Then usage would look like: # use protected; # my $ONE = protected->new; # $ONE = 'one'; sub TIESCALAR { my $class = shift; my $data = shift; return bless { data => $data }, $class; } sub FETCH { return $_[0]->{data} } sub STORE { return $_[0]->{data} } package main; my $THREE; tie $THREE, 'protected', "three "; $THREE = "four"; chomp $THREE; print "\$THREE >$THREE<", $/;
Be well,
rir

Replies are listed 'Best First'.
Re^2: Should chomping a constant always raise an error?
by BrowserUk (Patriarch) on Mar 11, 2005 at 05:23 UTC

    That would require anyone calling the sub to tie the constants--which makes no sense at all.

    It just took me by surprise that chomp died when asked to inspect a variable that was readonly. The work-arounds are myriad:

    1. The XS version of Scalar::Util has a readonly function.
    2. I could also use the eval block technique to catch the death. (Which is how the pure Perl version of Scalar::Util::readonly() does it.)
    3. The Internals package has a IsWriteProtected() function.
    4. I could use Inline::C to use the svREADONLY macro.
    5. etc.

    But, as chomp has to determine if there is anything to chomp, before attempting to modify it's argument, I just expected it to make that determination before checking for readonlyness. It doesn't do it that way, so I have to do extra tests or copies myself.

    I've gotten spoiled by Perl's DWIMming things like negative offsets don't die, they work backwards from the end. Same with negative subscripts; ranges that produce no values; empty lists that act correctly regardless of the context etc.

    On this occasion it didn't DWIM for me.


    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco.
      Oddly enough, if you use the Readonly module to mark your variable readonly, chomping will only fail if the variable is actually tried to be modified:
      #!/usr/bin/perl use strict; use warnings; use Readonly; Readonly my $msg1 => "Hello, world"; Readonly my $msg2 => "Hello, world\n"; chomp $msg1; # line 11 chomp $msg2; # line 12 __END__ Modification of a read-only value attempted at /tmp/ro line 12
      4. I could use Inline::C to use the svREADONLY macro.
      Done for you, in 5.8.0 and higher: Internals::SvREADONLY($sv)

        See number 3). :)


        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco.