Re: [PATCH] git-svn: handle leading/trailing whitespace from svnsync revprops

[Eric Wong <normalperson@yhbt.net>]

Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 3308fe1..f40ad2c 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -1758,10 +1758,16 @@ sub svnsync {
> >  	# see if we have it in our config, first:
> >  	eval {
> >  		my $section = "svn-remote.$self->{repo_id}";
> > -		$svnsync = {
> > -		  url => tmp_config('--get', "$section.svnsync-url"),
> > -		  uuid => tmp_config('--get', "$section.svnsync-uuid"),
> > -		}
> > +
> > +	        my $url = tmp_config('--get', "$section.svnsync-url");
> > +		($url) = ($url =~ m{^([a-z\+]+://\S+)$}) or
> > +	           die "doesn't look right - svn:sync-from-url is '$url'\n";
> 
> When I checked tmp_config(), I thought that it was returning the
> first element (taking the output of "config --get" as a
> LF-terminated list) when called in list context, so this would
> give the correct sync-url after stripping the trailing LF for
> Dennis's case.  The first assignment looks fine, but the second
> one looks very funny.
> 
> Is it only me who finds that
> 
> 	($var) = ($var =~ m{^(any regexp)$}) or die "message"
> 
> is extremely a roundabout and hard-to-read way to say:
> 
> 	if ($var !~ m{^(the same regexp)$} {
>         	die "message";
> 	}
> 
> which is much easier to read?

The statements are not equivalent, however.  I'd have to add

	$var = $1;

too, because I needed to extract what was inside the ( ) since the '$'
doesn't catch the trailing newline, either.  I also couldn't find any of
the /sm, /m, /s switches useful for making '$' not accept the trailing
newline, either.

I also consider the "or die " part of the line to be uninteresting,
and would rather not waste extra space on it.

> I said the first one looks fine, but actually I really _hate_
> Perl subs that use wantarray and return one element in scalar
> context, and return a list in list context.
> 
> This forces the programmer who calls the sub to read the code of
> the sub and know that it uses this unusual calling convention.
> It forbids them to rely on their common-sense acquired from
> experience while coding in Perl, that most functions do not do
> that, and a usual sub that is capable of returning a list in a
> list context you can find out the number of elemenets, the first
> element, and the first few elements by using:
> 
> 	sub returns_list {
>         	my @a = qw(a b c);
>                 return @a;
> 	}
> 
> 	my $number_of_elems = returns_list();
> 	my ($first_element) = returns_list();
> 	my ($first, $second) = returns_list();
> 
> IOW, writing
> 
> 	sub returns_funny {
>         	my @a = qw(a b c);
>                 return wantarray ? @a : $a[0];
> 	}
> 
> may make you feel as if you have become a power-coder, and might
> even give you a false sense that some parts of your code can
> become simpler thanks to that, because you can now write:
> 
> 	my $first_element = returns_list();
> 
> i.e. you did not have to type WHOLE TWO LETTERS ( and )!
> 
> But in the longer run, when you want/need other people to help
> maintaining such a code, you create unnecessary burden on them.

Good points, I've been mindlessly taking "interesting" things from other
Perl code I've seen over the years and using it in my own without
thinking about it too hard :x

I'll avoid them in the future.  Unfortunately, Git.pm also suffers from
this as well.

-- 
Eric Wong