Re: What use is the Schwartzian Transform?

[Michael Cramer <cramer@webkist.com>]

I disagree with the main assumption: I don't think C is particularly clear.

mjd-perl-pm@plover.com wrote:
>         # Code A        
>         my @filenames = readdir D;
>         @sorted = sort { -M $b <=> -M $a } @filenames;

Obviously, @filenames go in one side and come out the other side sorted 
by whatever -M does. Structurally very clear.

>         # Code B 
>         my @filenames = readdir D;
>         @sorted = map { $_->[0] }
>                   sort { $b->[1] <=> $a->[1] } 
>                   map { [$_, -M $_] } @filenames;

Less clear, but even a quick glance tells me that @filenames are going 
in one side and a sorted list of something comes out the other side.

>         # Code C
>         my @filenames = readdir D;
>         my %date;
>         $date{$_} = -M $_ for @filenames;
>         @sorted = sort { $date{$b} <=> $date{$a} } @filenames;
>         undef %date;
A quick glance says we're filling up a hash with some dates (with 
@filenames, but the for loop is a bit unclear unless you use it that way 
often). And then we sort the filenames using those dates again, which we 
then throw away. But why again did we create it?

> So here's the question:  why do we bother with B at all?  Why not
> always use C?

I would say that if you are going back, looking at every single 
statement and determining exactly what is happening, sure, A is easiest, 
and C is easy enough to figure out. But to be honest, when I debug 
someone else's code I look at the code from a distance first, and 
hopefully everything is set up logically enough that I don't have to 
examine every single statement. Sure, in B I couldn't be *sure* that I 
was getting out a list of filenames sorted by -M, but a simple change 
would fix that:

	# Code B
	my @filenames = readdir D;
	# Sort the filenames by modification time.
	@sorted = map { $_->[0] }
	          sort { $b->[1] <=> $a->[1] }
	          map { [$_, -M $_] } @filenames;

Now, unless the files are coming out in the wrong order -- a bug that 
*hopefully* would not outlive the author's employment -- a  maintainer 
down the road can just ignore the whole block.

Obviously, you can add the same comment to any of the versions with the 
same effect, but there is still one thing in C that could bite the 
maintainer: trying to use a hash called %date in the surrounding code. 
At best he's going to get a '"my" variable %date masks earlier 
declaration in same scope...' At worst he's going to get an empty hash 
when he expects it to be full.

So, if you are building code that someone else will have to maintain, 
feel free to use the S.T. -- just add a comment saying what you're 
sorting on. If you can't be bothered to do that, chances are the rest of 
your code is going to be just as impossible to maintain.

--
Mike Cramer
http://www.webkist.com/ | AIM: MikeWebkist
-
**Majordomo list services provided by PANIX <URL:http://www.panix.com>**
**To Unsubscribe, send "unsubscribe phl" to majordomo@lists.pm.org**