Re: [Bug-wget] Big refactoring

[Micah Cowan]

On 08/07/2012 06:18 PM, illusionoflife wrote:
> On Tuesday, August 07, 2012 11:08:40 you wrote:
>> I think the maintainer is aware that Wget's code quality is poor, and
>> would welcome sweeping architectural changes; I know I would have, when
>> I was maintainer.
> Of course, but we can have different points of view what improvement is.
>>> I fed wget source to GNU complexity and It suggested me to look at
>>> parse_netrc. So I came with some ideas -- they are not so fast to
>>> implement, so I want to discuss them, to not waste work.
> 
>> To my mind, there are many more monstrous functions than parse_netrc.
>> And in parse_netrc's case, I'm guessing most of the code is fairly
>> single-minded. In cases such as gethttp or http_loop, those functions
>> "know" way too much about various subsystems, and take responsibility
>> for far too much, in addition to being simply behemoth in size.
> They will get their hour.
>> Not to my eye. I can instantly understand what the while-loop does,
>> whereas the function is a mystery to me until I actually inspect it. I
>> do not believe that one- or two-line functions add value (and they
>> usually detract), except in cases where the implementation might change,
>> and needs to be gathered to one spot. I do not think that scanning for a
>> category of character qualifies.

> Okay. I would like to hear more opinions. Because for me, two-line loop and 
> comment before is worse then function with speaking name. 3 lines vs 1.

A name is often worth very little. It's worth more, the larger the
functionality that it represents. But more often than not, you find
yourself having to look up the function anyway, to find the specifics of
how it works. I usually do, anyway. When it's a two-line function body,
it's simply not worth that extra hassle.

And it's 2 lines vs 1, not 3 - a comment is hardly necessary for such
exceedingly simple code. But even 3 lines, quickly read and immediately
available, is better IMO than 1 line, referring to a function body you
have to find elsewhere, whose body then consists of 2 lines that would
only have taken an extra line of space above the invocation, and no
extra time to look up.

I do agree with the general principal you're promoting, which is to
replace oft-repeated bits of functionality with clearly-named functions
that identify what they do. But I also think there are extremes to which
it can be applied, and that this qualifies as an example.

>> We're already inextricably tied to gnulib at this point, we might as
>> well take advantage of any facilities already offered to us there.
>>
>> And I suspect gnulib will have a number of facilities that may help in
>> the refactoring effort anyway.

> Yes. But what about list.h?

What about it? I'm not understanding your question. You keep mentioning
using list.h, but using WHAT list.h? Wget doesn't have a list.h, so
whose list.h are you talking about? And why is it better than, say,
using gnulib's "list" module (with gl_list.h, etc)?

-mjc