water, thank for this meditation. I've been fighting with several modules that I've installed at home on Linux that work just fine, but fail miserably on my Windows box at work because of this very issue.

I'd just like to add on point though. If you do run into a module that you use on CPAN that fails because of this issue and you take the time to fix it, please take the time to put together a patch for the developer of the module and the public at large. Although it may be a pain to go through this extra step, your helping out the community at whole by making your work available.

The loss in readability between:

    $file = "fnord/glop/bibba";
[download]

    $file = File::Spec -> catfile (qw /fnord glop bibba/);
[download]

The XP folks wisely warn against designing in extra functionality "just in case"

Writing from the middle of an XP-to-Linux port

Abigail

It seemed pretty clear that the first XP was 3) and the second was 2).

ActiveState perl already understands that slashes and backslashes are equivalent for most modules. This is not to say everything in CPAN will be friendly, but in all of my Windows scripts I just use "/" like normal -- and I haven't had any problems unless I am sending something to the shell.

In the rare cases where I had to do this, a simple fix_path function is usually sufficient to insert (which turns slashes into backslashes). I *do* need to look at File::Spec and others in these cases, but in general, conciseness is important to me when it can be done without causing problems. And when only dealing with Windows, Linux, and basic Unix systems, this is good enough for me. I'll capitulate when I have to port to something more obscure, I'm sure.

I've never had a problem with ActiveState not translating between "/" and "\" in a path. The main problem I've had is with the tests, where a path in a string is "t/foo/bar" and Windows returns "t\foo\bar". This is enough to cause a test and CPAN install to fail.

When I first started doing DBI stuff, I made the mistake of thinking, "I thought out this table design carefully, so I'm never going to add or change any fields." So I hardcoded the fields:

my $q=$dbh->query("INSERT INTO foo VALUES (?,?,?,?,?);
$q->execute($bar, $baz, $qx, $qux, $quux);
[download]

Hah. Don't ever do that. You end up tracking down every single query in your code and fixing it. Multiple times.

I think one of the reasons File::Spec is not used more is that the default interface is ... erm ...strange. File::Spec->catfile(...)? Beg your pardon?

Yeah OK so it uses inheritance to allow the default implementations of the functions to be overriden ... but that's just an implementation detail. And implementation details should not leak into the interface.

The interface provided by File::Spec::Functions is the one that should have been the default one. It looks like the interface of most Perl modules, it allows you to import (or not) functions into your namespace just like any other well behaved module.

A module that's OO and provides only static methods has no reason to be OO at all. This aint Java.

Actually it seems to me OO inheritance is not the best implementation. It's slow. There is no reason why the right versions of the functions could not be found just once, on startup. I think it would be better to do something like this:

#SpecBase.pm
package SpecBase;
require Exporter;
@ISA = qw(Exporter);
@EXPORT = @EXPORT_OK = qw(foo bar);

sub foo { print "The base foo()\n"; }
sub bar { print "The base bar()\n"; }

1;

#SpecChild
package SpecChild;
require Exporter;
@ISA = qw(Exporter);
@EXPORT = @EXPORT_OK = qw(foo bar);

use SpecBase qw(foo); # the inherited functions, to prevent the "Subro
+utine bar redefined" warnings

sub bar { print "Overwritten bar()\n"; }

1;

#Spec.pm
package Spec;
...
sub import {
 shift();
 ... find out the right version
 require $the_right_version;
 $the_right_version->import(@_)
}
1;
[download]

Update: Actually looking into the code in File::Spec::Functions I see that the inheritance tree is not being searched through each time. The right method is found by the ->can(). But I think the closure also is not free.

Edit by castaway: Closed small tag in signature

I think one of the reasons File::Spec is not used more is that the default interface is ... erm ...strange. File::Spec->catfile(...)? Beg your pardon?

That's why Ken Williams, who maintains File::Spec, wrote Path::Class. It's a really, really nice object oriented module for path manipulations. Check out the Synopsis section of its POD to see how much better it is.

---

Once it's Turing complete, everything else is just syntactic sugar.