On Wed, Apr 16, 2014 at 7:19 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Junio C Hamano <gits...@pobox.com> writes:
>
>> Erik Faye-Lund <kusmab...@gmail.com> writes:
>>
>>> So let's manually check for these in that case, and fall back to
>>> the File::Spec-helper on other platforms (e.g Win32 with native
>>> Perl)
>>> ...
>>> +sub file_name_is_absolute {
>>> +    my ($path) = @_;
>>> +
>>> +    # msys does not grok DOS drive-prefixes
>>> +    if ($^O eq 'msys') {
>>> +            return ($path =~ m#^/# || $path =~ m#[a-zA-Z]\:#)
>>
>> Shouldn't the latter also be anchored at the beginning of the string
>> with a leading "^"?
>>
>>> +    }
>>> +
>>> +    require File::Spec::Functions;
>>> +    return File::Spec::Functions::file_name_is_absolute($path);
>>
>> We already "use File::Spec qw(something else)" at the beginning, no?
>> Why not throw file_name_is_absolute into that qw() instead?
>
> Ahh, OK, if you did so, you won't have any place to hook the "only
> on msys do this" trick into.
>
> It somehow feels somewhat confusing that we define a sub with the
> same name as the system one, while not overriding it entirely but
> delegate back to the system one.  I am debating myself if it is more
> obvious if it is done this way:
>
>         use File::Spec::Functions qw(file_name_is_absolute);
>         if ($^O eq 'msys') {
>                 sub file_name_is_absolute {
>                         return $_[0] =~ /^\// || $_[0] =~ /^[A-Z]:/i;
>                 }
>         }
>

In this case, we end up requiring that module even when we end up
using it, no? Not that I have very strong objections for doing just
that, after all, it appears to be built-in. (As you might understand
from this message, my perl-fu is really lacking :-P)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to