Well, moved into new Sydney place ok. All the hard drives survived the moved ok.
The new place is a totally stereotypical geek share house.
"Hi, come on in. So, the switch is over there, and there's wireless, but a bit weak upstairs. The two X-Boxs are over there. Oh, and we're ordering takeout"
Yep :)
Should be a great place to settle back into living in Sydney for 6 months or a year or something.
In CPAN news, we cracked the big 10,000 modules WAY faster than I expected, thanks to someone unleashing a dozen new Kwiki modules on the world. And thanks to everyone else that released as well.
In addition, I've realised that I'm going to have to change the File::HomeDir API, seeing as there are some situations where the user has nothing whatsoever that could be construed as a "home directory".
So all methods are going to need to change to return undef in this case. Note that this doesn't change the fact that File::HomeDir will -d and confirm a directory exists before returning it, it just means you are going to need to work out for everything that uses it how to deal with no-homedir situations, and this will force people into it.
I've filed about 15 rt.cpan.org bugs with the people that use it I can detect, so they (and you) have a couple of months before I make the actual change.
Hopefully there won't be too much trouble, as currently File::HomeDir just dies in the situations that have no home directory.
Re:Why undef?
Alias on 2006-05-18T16:49:32
A die would indicate an exception, something we don't expect to happen.
In fact, File::HomeDir already has a number of these in it. Generally, it's things like failing to find a directory where it is expecting one. If someone hacked their OS X directories to something unusual, you might see it.
However, as I push outwards to try and cover more platform and situations, I'm finding that lack of a home directory is much much more common than I had thought (or than the original author thought as well I suspect).
It's reached the point where I think people are going to have to think about dealing with it in order to have their module available to a reasonable group of platforms.
For example, if you try to install a module on OS X as root, well then there's no home directory for it, and tests are going to fail. Currently, they die, so they fail at File::HomeDir itself. Any problems further up will so far have been masked.
But in any case, not having a home directory isn't looking like an exception-to-the-rule at all.
So we have two possibilities.
1. Die and tell people that they need to care.
2. Return false.
If we do 1. then people will need to do something like this every time you call a File::HomeDir method.
my $home = eval { File::HomeDir->my_home; };
if ( $@ ) {
# Trap the no homedir case, and rethrow the rest
if ( $@ =~/does not have a home directory/ ) {
# handle that case...
} else {
die $@;
}
}
If you DON'T trap the case, it dies.
That code is pretty evil. So the alternative of a "normal" false return is better.
We can't return the normal boolean false null string, because that is going to be legal as "current dir" in some expressions, or otherwise not error properly.
my $home = File::HomeDir->my_home;
my $conf = "$home/.foo";
IF we use a null list, then this gets broken...
my $conf = File::Spec->catdir(
File::HomeDir->my_home,
'.foo',
);
Which leaves undef. It will work in boolean cases...
my $home = File::HomeDir->my_home
or die "You don't have a home directory";
But also, it will create plentiful warnings or outright exceptions get thrown when it is used but isn't checked.
So it's mostly a case of looking out for the both the DarkPAN and people writing new code. If there is a lot of code out there that currently assumes a true return, then returning undef is the best combination of "induces failures" + "compact to code against" I can think of.
I'd be open to something better though
