Re: [PATCH 5/7] gitweb: auxiliary functions to group data

From: Jakub Narebski <jnareb@gmail.com>
Date: Sep 17, 2010, 17:17 UTC
Message-ID: <201009171917.44979.jnareb@gmail.com>
In-Reply-To: <AANLkTikjLNva7Jgh0xYeah1maFusfOiaLwY7+eixx8so@mail.gmail.com>

On Fri, 17 Sep 2010, Giuseppe Bilotta wrote:

Show 32 quoted lines

> On Fri, Sep 17, 2010 at 6:06 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Giuseppe Bilotta wrote:
>>> On Fri, Sep 17, 2010 at 3:24 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>
>>>> ... but I think that having separate subroutines for opening and
>>>> closing tags is a bad design / bad API (except in some rare cases).
>>>> It is begging for unbalanced HTML.
>>>>
>>>> It would be better if it was a single subroutine wrapping 'div' around
>>>> contents given either as a string, or via callback (subroutine reference),
>>>> in my opinion.
>>>
>>> I'm not sure that in this case the string or callback approach would
>>> be any cleaner. I'll see if perl supports closures or something like
>>> that.
>>
>> Perl supports closures (thanks to anonymous subroutines 'sub { ... }'
>> and lexical variables 'my $var'), see perlsub and "Function Templates"
>> in perlref.
>>
>> I also recommend free ebook "Higher-Order Perl" http://hop.perl.plover.com/
> 
> Thanks for the suggestion. I'm still not convinced that such an
> implementation would be better though. Aside from the general
> aesthetical suckiness of passing closures around (and the experience
> is not any more pleasurable in Perl), there's also the matter of the
> calling convention to use. I can think of two options:
> 
> (1) we make the function callable as git_do_group($class, $id, sub {
> <closure that prints the content> }, <paramters that go to
> git_print_header_div>), which is somewhat illogical since we're
> specifying the content before the header,

Why not

  git_do_group($class, $id, <print_header_div parameters>, sub { ... })

or even use subroutine prototypes? We can use 'pop @_' to get last argument of a subroutine.

[...]

> Overall, I still get the impression that the current API is
> considerably cleaner, even with the small counterweight of the risk of
> leaving groups open (which is not something so dramatic anyway, IMO).

Might be.

But as currently git_*group() is used in only one place, isn't it premature generalization ;-) ?

-- 
Jakub Narebski
Poland