On Tue, 08 Aug 2000, Brandon wrote:
> > There is no easy to follow main thread of execution, instead you have one
> > method calling the next calling another. That is why things like trying
> > re-enter on bad data or even trying to get ahold of the message id after 3
> > jumps between differnet methods becomes so difficult.
> 
> The lack of an easy to follow thread of execution is simply because I had
> the methods in no particular order. I just arranged them in their proper
> order and the thread of execution is quite clear. They now always call
> down and the methods are discreet, overridable, replacable chunks of code.

In RequestClient.main you first call a constructor with the args which makes an
instance of the RequestClient object. Then you call execute on that object,
which calls doExecute in RequestClient, which then starts _another_ instance of
RequestClient which it calls request on, only to go back to the first instance
to call ProcessReply (which calls a number of other methods with numerous
undocumented sideeffects). I'm not even clear about where a person using this
as a library is supposed to enter...

> > I have nothing against functional coding, but a function should represent
> > a mathematical map of input -> output. Just splitting the chunks of code 
> > into a
> > hundred public methods will only make life hell for people trying to use 
> > this.
> 
> Any code which could be overriden by a subclass (reasonably) should also 
> be its own method.

Being as compact as possible is not the end all be all of elegant code. If
having to repeat two lines somewhere makes the code sanely readable, then it is
worth it.  Methods should represent some logical operation - it does not matter
if it might be useful to override just a single line somewhere, because the
coder doing the overriding is unlikely to be thinking exactly like you are and
won't pick up on it.

Also there is the OO thing - for all the methods you created, you put them all
in the same class, although it would have made more sense in several places to
attach them to the object on which they act instead.

> The reason that there are so many methods is actually because
> there are two distinct units in the code which should actually be split
> into different classes, the code for sending a insert/request and handling
> the thread of messages necessary to properly insert/request something, and
> the code which wraps around that, doing things like parsing command line
> arguements, encrypting the file, etc.. I was just in the process of
> splitting the classes into two, but I'll wait for you to commit.

But these were actually seperate when you started (one being in the static
code, the other in the object instance), you were the one who decided to cut it
into little chunks and put it in the food processor.

> > It's been two months Brandon...
> 
> I'm not sure what you're saying here. That I should have done more in the
> last two months to fix up the ugly client code which I mostly didn't
> write? Well I did my best while working 12 hours a day, taking summer
> classes, administrating the mailing lists, and going to two
> conferences. If only there were more hours in the day. But please, come
> down with your Godlike coding prowess and fix it.

You need to be able to some critisism. If the two people who are doing the most
work on this project complain, they may well be wrong, but it is probably not
out of spite. I have been made aware of the lackings in my code on a number of
occations, and I make no excuses for the fact that some of the stuff I wrote
this winter and spring was rubbish. 

And no I don't expect you to have as much time to work on this as I have - most
of the people in the world have no time to work on Freenet at all, and I don't
hold that against them. I don't think there is anything wrong with the fact
that Ian's raw contribution to the code has slowed since he became the only
sane voice in the world media either. Every man to their own - I was just
trying to point out that it's been more then two months, if reconsidering the
interface wasn't an option in that time, maybe you should have let it be.

> 
> 
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
-- 
\oskar

_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to