in reply to Re: Playing with non-localized $_ in nested loops.
in thread Playing with non-localized $_ in nested loops.

I've often wished that $. could be %. instead. That way, $.{FH} could refer to <FH>, and $.{DATA} could refer to <DATA>. But this all breaks down when you start talking about lexical scalar filehandles ( <$fh> ), because how would you write that? $.{\$fh}? ...it starts looking a little ackward.

I've also often wished that it would actually "do" something when you assign a number to $. But of course this is asking way too much of the buffered IO subsystem, and when that sort of behavior is desired, it's almost always easier to just use Tie::File.


Dave

Replies are listed 'Best First'.
Re^3: Playing with non-localized $_ in nested loops.
by QM (Parson) on Aug 23, 2004 at 21:49 UTC
    I've also often wished that it would actually "do" something when you assign a number to $.
    Just think what this would mean:
    $. = 10.7;
    Does that mean we can now start reading from the character at position 70% on line 10? Or is that the 8th character? [And how do I get rid of the headache that just gave me?]

    -QM
    --
    Quantum Mechanics: The dreams stuff is made of

      Perl dwims nicely when you use a float in other situations where an int is expected.

      my @a = 0 .. 9; print $a[3.5]; 3

      It could do the same here. If the number involved required advancing from the current position, it just reads and discards enough lines to get to where you want to be.

      The problem arises if you want to backup. That would require keeping the file positions of every line seen so far. On large files, that's a lot of storage. If you store integers in a perl array, they take as much space as storing the lines themselves until the lines get greater than 20 chars or so.

      You can save some space by storing the offsets in a C-style array (eg. pack them into a string) but with if your going to handle files greater than 2/4GB, then you need to store 8 bytes/line, and that still chews a substantial amount of memory to provide a rarely used facility.

      Though, I guess if it rewound to the beginning and discarded until it reached the position required it wouldn't require extra storage. It would simply be doing what you have to do yourself to achive the same results, but hiding it behind a simple assignment... which might be nice.


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
        I appreciate your reply, and you make very good points.

        However, I was being a bit cheeky by suggesting that it might be useful to assign $_ a float, and have it position the file pointer in the middle of a line appropriately. But it gets to be a bit of a headache to decide if 10.7 is the same as 10.07 or 10.70.

        -QM
        --
        Quantum Mechanics: The dreams stuff is made of