Re: {3} Using Variables in Path Names

[jeroenes]

I think tadman ment 2 things. First of all, with the join method you only have a hard-coded separator in one place. If you want another, just replace that one, or better, define a variable for that.

Two, you'd better assign variables, or arrays, to define the subdirectories node for node. That way, the code gets more readible (less comments needed) and better maintainable.

Jeroen

[dragonchild]

This is actually an interesting discussion. Let's take a look at the code for this:

# Having defined $HOME, $first, $second up above somewhere...
# Using interpolation
my $dir = "$HOME/$first/$second";

# vs. Using join
my $dir = join '/', ($HOME, $first, $second);

Personally, I find the first to be more expressive. It tells me, the reader, that you're talking about a directory structure because that's how I'm used to seeing it.

join, to me, talks about creating generic strings, usually for some cryptic file using comma-delimitation or as a way of printing out an array in a readable form.

Now, this is all personal style. I guess I'm just used to seeing it that way.

As for speed ... I haven't done the Benchmarking, but I think that interpolation might actually even be faster.

As for usability, I will agree that it's easier to manipulate a list vs. manipulating a string, but that usually doesn't really matter. Most of the time, you're manipulating said string in a recursive fashion. So, you're just adding vs. adding & subtracting (which you'd have to do if you converted the recursion to a loop).

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[IlyaM]

My 0.02.

I don't like both variants. They are not portable. It is better to use File::Spec for operations on filenames:

use File::Spec;
my $dir = File::Spec->catdir($HOME, $first, $second);

[tadman]

I suppose my rationale behind using join over string interpolation was that when working with directories, it is often advantageous to use an array instead of a string. This way you can resolve path components like '..' using pop instead of a regex. The other idea was that each piece supplied to the join would represent a single path component, which could be validated using a quick map for the extra paranoid. Of course, then $HOME would have to be split into something like @HOME.

Anyway, Benchmark says:

Benchmark: timing 1000000 iterations of interpolator, joiner...
interpolator:  5 wallclock secs ( 5.13 usr +  0.00 sys =  5.13 CPU) @ 
+194931.77/s (n=1000000)
    joiner:  4 wallclock secs ( 4.53 usr +  0.00 sys =  4.53 CPU) @ 22
+0750.55/s (n=1000000)
                 Rate interpolator       joiner
interpolator 194932/s           --         -12%
joiner       220751/s          13%           --

From:

#!/usr/bin/perl

my ($the,$fastest,$donut,$youve,$ever,$seen) = qw [ the fastest donut 
+you've ever seen ];

sub joiner
{
        my $x = join ('/', $the,$fastest,$donut,$youve,$ever,$seen);
}

sub interpolator
{
        my $x = "$the/$fastest/$donut/$youve/$ever/$seen";
}

use Benchmark qw [ cmpthese ];

cmpthese ( 1000000, {

        joiner       => \&joiner,
        interpolator => \&interpolator,
}
);

[impossiblerobot]

As far as I can tell, using 'join' or the concatenation operator(.) are both reasonably fast; interpolation is slower than either. Of course, you would have to do a lot of joining for it to make any difference in the speed of your program.
If interpolation is more readable (which I think it is), you could always do this:


my $dir = $HOME.'/'.$first.'/'.$second;


for the extra speed boost. :-)
(Actually, that's kind of ugly, too. I would probably just interpolate.)

Impossible Robot