Re: [Pybeep-devel] Code cleanup

[Gabe W. <gw...@wa...>]

Sean-
	I just committed some code (that doesn't work, but its been
uncommitted so long - tests now break).

	Generally, I'm supportive of your plans - comments inline:

On 11 Mar 2002, Sean Allen wrote:

> Hi
>
> I started looking into the existing code-base to try and clean up some
> of it this weekend. Sheesh.

Hehe! Nobody said it was pretty.

> I think, one of the next steps forward (and quite an important one) is
> to decide what we don't want in the core anymore (eg. the datastream
> stuff) and cut it out soon, as its really starting to get messy in
> there. I'm loosing track of which stream I'm meant to be reading from.

Yeah, thats a good idea. I think the only real cruft is the stream stuff
(other than the DataQueueStream). I think your confusion is because the
transition is not quite complete and the cruft has not yet been removed.
We'll have to hook up on IRC so I can give you more details.

As for unifying into one file - I'm all for that, but I had hoped to wait
until the last minute so we could work on separate files so as to make CVS
merging less frequent. At this point I'm really hestitant to push
everything into one file. More comments inline...

> My suggestion is also to begin to unify the core into a single namespace
> (i.e one .py file), the reasoning for this is:
>
> 1) It's more natural.

Absolutely!!! Before we have a 1.0 (or even .9) we *will* merge into a
single module (file).

> 2) it avoids multiple copies of stuff loaded into various namespaces.

Yes, although I don't know where this is an issue with what we have.

> I'm not advocating premature optimization, but it seems pointless to
> have 5 copies of the same constant sprinkled out through 5 or 6 files

I'm pretty sure we do *not* have the same constant defined in multiple
places. At least we *shouldn't* - I tried to make sure that constants were
syntactically contained in the module they related to but even then they
shouldn't have naming conflicts (ie no constant should be defined in two
modules). I've always had the plans to merge everything into one python
module/file.

> 3) It will be neater.

Oh yeah!!!

> Basically, core.py will be a large file,but I feel it will be easier to
> manage and will only include the classes we need. We can also trim those
> classe quite a bit(a lot of stuff in channel/session etc seems to be
> Java specific and unnecessary).

As for trimming - maybe.

> What I am proposing is this.
> 1) Trim and unify the core classes(Session, Channel, Message, Frame,
> Scheduler etc.) into core.py, this would also mean dropping a few and
> maybe moving the functionality into a single class (i.e. the
> MessageStatus/Message issue)

Actually messagestatus and message should be separate. I'm not sure there
are any *classes* we should drop. Very likely some methods aren't
neccesary.

I've been focusing on getting functionality rather than prettiness.

> 2) Unify utility classes (Synchronizable, a single Queue implementation
> etc.) into a util.py

OK, but why not in core.py?

<plans niceness="evil" scale="world-domination">
I mean, ideally we're going to produce beep.py which will just go in the lib
directory of the Python distro.
</plans>

> 3)leave the tests as is, but adapt them for new architecture (changing
> imports basically)

Yeah.

> If nobody has any objections, I would like to work on this over the next
> week, as it is, IMHO really necessary, it's getting hard to navigate the
> source now.

I agree the source is confusing, but I really don't want to smush quite
yet. What I *do* want to do is the other stuff you mention (in particular)
because it is confusing.

I'll try to catch you on IRC tonight, if possible - we can discuss
specifically what to do.

Until then, if you'd like to compile a list of specific changes you want
to make absent the smushing, that'd be a very useful specific list to
discuss...

	-Gabe

-- 
Gabe Wachob                   gw...@wa...
Personal                   http://www.wachob.com
CTO, WiredObjects    http://www.wiredobjects.com