Re: [Automake-NG] [PATCH 4/4] [ng] cleanup: after enabling of subdir-objects unconditionally

[Stefano Lattarini]

On 06/08/2012 11:59 AM, Akim Demaille wrote:
> 
> Le 8 juin 2012 à 11:47, Stefano Lattarini a écrit :
> 
>>>> @@ -5068,11 +5057,6 @@ sub check_gnits_standards
>>>> #
>>>> # Functions to handle files of each language.
>>>>
>>>> -# Each 'lang_X_rewrite($DIRECTORY, $BASE, $EXT)' function follows a
>>>> -# simple formula: Return value is LANG_SUBDIR if the resulting object
>>>> -# file should be in a subdir if the source file is, LANG_PROCESS if
>>>> -# file is to be dealt with, LANG_IGNORE otherwise.
>>>> -
>>>> # Much of the actual processing is handled in
>>>> # handle_single_transform.  These functions exist so that
>>>> # auxiliary information can be recorded for a later cleanup pass.
>>>> @@ -5105,33 +5089,34 @@ sub lang_c_rewrite
>>>>                    uniq_part => 'AM_PROG_CC_C_O per-target');
>>>>       }
>>>>    }
>>>> -
>>>> -  return LANG_SUBDIR;
>>>> +  return;
>>>
>>> Pretty useless.
>>>
>> Nope: in perl, if you don't use an explicit 'return' at the end of a
>> subroutine, the value of the last expression (whatever that might be)
>> is returned:
>>
>>    $ perl -e 'sub foo { my $x = "oops"; }; print &foo . "\n";'
>>    oops
>>
>> So the above return is actually needed -- automake dies of an internal
>> error if it's not present!  Do you want me to add a comment to clarify
>> this?
> 
> Yes, definitely.
>
What about this?

    # Not a useless use of return: the caller of this subroutine will
    # behave differently if a value is actually returned, and since perl
    # returns the value of the last expressions seen by default, we
    # need to explicitly return and undefined value.
    return undef;

> I'd like to know more about the error actually.
> It must be that the other side is actually expecting a value.
> So IMHO, the caller should be fixed.
>
No, the caller (handle_single_transform) deliberately discriminate between
"no returned value" and "returned defined value" to decide whether it needs
to so some more processing:

    # The language rewrite function can return a new source
    # extension which should be applied.  This means this
    # particular language generates another source file which
    # we must then process further.  This happens, for example,
    # with yacc and lex.
    my $subr_rewrite = \&{'lang_' . $lang->name . '_rewrite'};
    $subr_rewrite = sub { } unless defined &$subr_rewrite;
    my $source_extension = &$subr_rewrite ($directory, $base, ...)

>>> { 1; }
>>>
>> As the Zen goes, "Explicit is better than implicit" :-)
>> But I'll do the change if you insist.
> 
> I mostly agree with your Zen,
>
It's not mine, it's Python's ;-)

> but I strongly disagree that
> it applies here.  Every single modern language, especially
> functional ones, have the "return" unnecessary.
>
Not the case for Python.

> Consider "return" as a means to break flow control, not as a
> means to specify the returned value.
>
OK, I will do the change in this case, since the context is clear enough
account for the missing 'return'.

>>>> +# Vala '.vapi' are a kind of header files as well, and should
>>>> +# not be processed into compilation rules.
>>>> + sub lang_vala_ignore
>>>> {
>>>> -    # Header files are simply ignored.
>>>> -    return LANG_IGNORE;
>>>> +    my ($directory, $base, $ext) = @_;
>>>> +    return ($ext =~ m/\.vapi$/ ? 1 : 0);
>>>
>>> No return, no parens.  etc.
>>>
>> See above.  The fact that perl allows us to be obscure is not a good
>> reason to be obscure.  Removing the return and the three-way conditional
>> would seriously hurt readability IMO.
> 
> Not my opinion :)
> 
But I won't do the change here, since readability would be truly hampered
(for me at least).   Hope that's OK with you.

Thanks,
  Stefano