Re: [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script

[Peter Vereshagin <peter@vereshagin.org>]

God love is hard to find. You got lucky ??var!
2010/05/13 17:13:12 +0000 ??var Arnfj??r?? Bjarmason <avarab@gmail.com> => To Peter Vereshagin :
vArB> 2010/5/13 Peter Vereshagin <peter@vereshagin.org>:
vArB> > Hey Mr(s) Jakub show some good to me!
vArB> > 2010/05/11 15:51:15 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
vArB> > JN> On Tue, 11 May 2010, Peter Vereshagin wrote:
vArB> > JN> > 2010/05/11 12:58:50 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
vArB> > JN>
vArB> > JN> > > > > I have changed this 'exit' to non-local goto to toplevel.  It could be
vArB> > JN> > > > > done instead by redefining 'exit' subroutine, like shown below, but I
vArB> > JN> > > > > feel that would be hacky if you can change gitweb code (it is not
vArB> > JN> > > > > black box you should not touch).
vArB> > JN> > > >
vArB> > JN> > > > Right, one shouldn't ever redefine perl built-in functions. I did only because
vArB> > JN> > > > of no other way to 'get things working'
vArB> > JN> > >
vArB> > JN> > > Why not?  For example CGI::Carp redefines 'die' to log errors.
vArB> > JN> >
vArB> > JN> > Ouch, sorry, I meant 'last' or something like that.
vArB> > JN>
vArB> > JN> "last" / "last LABEL" is a command, not a function, therefore you cannot
vArB> > JN> redefine it.
vArB> >
vArB> > it's a flow control statement thus it is a built-in thing same way as any other
vArB> > functions are explained in a 'perldoc -f'
vArB> > Therefore it is treated by monkeys crowd as function. It's obvious for me to
vArB> > stay out here ( here != maillist ) yet in such an environment.
vArB> 
vArB> These things are called "operators" in Perl, some of them (like exit)
vArB> you can redefine. Some (like last) you can't. At least not without
vArB> some deep magic.

problem is not the naming, but that those are built-in and supposed to be used
'as is'. Operators or functions are whatever, but for perldoc they are the '-f'
so think not a big problem I named them functions.

vArB> > Anyway, I compare last() here  with exit() and die() which look to user just
vArB> > like the same kind of: the flow control statements. I guess any perl user who
vArB> > makes things like gitweb ( at least as a CGI-only app ) shouldn't care about
vArB> > such an internal difference of flow control statements those are
vArB> > hidden/incapsulated inside the implementation of those statements?
vArB> > Needless to mention that the 'last LABEL' ( goto, gosub, ... named them )  is a
vArB> > bad and a very deprecated style which is every schoolboy is aware about
vArB> > nowadays to keep from using in the application, not system, programming in imho
vArB> > every language.
vArB> 
vArB> `last LABEL' is not bad or deprecated. It's what you use to get out of
vArB> nested for-loops in Perl:
vArB> 
vArB>     OUTER: for my $i (1 .. 10) {
vArB>         for my $j (1 .. 10) {
vArB>             last OUTER if $i == 5 and $j == 5;
vArB>         }
vArB>     }
vArB> 
vArB> goto is also recommended in some cases in Perl. That's because it
vArB> doesn't do the same thing as in C:
vArB> 
vArB>     # Don't create a stack frame
vArB>     sub foo { goto &bar }
vArB> 
vArB> Anyway, arguing over which control flow operator is evil in an
vArB> imperitive language is just splitting hairs. Certain uses of them are
vArB> a bad idea, not the operators themselves.

correct, just use-cases are a thing to change like cgi to fastcgi environment,
this is where exit() is intended to be redefined for performance reasons. Thus
original uses are not as certain as they were supposed to be at the moment of
applications' coding: there were no idea why the END{}'s exit() is any better
than the explicit in-code one. It's just can cause the lack of the performance
and should be avoided in persistent perl processes to serve such a CGI-like
applications.

73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB  12F8 0CE1 4AAC A0E2 6627)
-- 
http://vereshagin.org