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

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)