On (09 Apr 95) Eric Schonning wrote to Chris Adams...
 ES> that was me.  Bob Harris used to ask me to look at the rbbs source
 ES> code
 CA> I thought so.      ^^^^^^^^^^ Sounds semi-familar, was he running a BB
 CA> in 805 in the last year?
 ES> He ran HIS Board.  He moved to Pensacola, Fl beginning of march this
 ES> year though and hasn't gotten the bbs fully up again yet.
I KNEW I'd heard his name before...
 CA> Yeah. Like that EBBS that came on the PB/XTRA disk, it was okay to
 CA> compile, but a real pain to mod.
 ES> I have never looked at that code.  I think its also posted on the PB
 ES> BBS as well as being on those disks.  Just too much going on to mess
 ES> around with other people code...
Not really worth it. Making major changes would take forever!
 CA> I generally use GOSUB only for error/event handlers (Why can't they ad
 CA> subs?) and GOTO only for REALLY complicated looping if/then structures
 CA> (like what I got in my project for trig, which suffered from
 CA> "Just-one-more-feature"-itis)
 ES> Yeah I often wondered why it was an "ON ERROR GOTO" sort of thing and
 ES> "ON KEY GOSUB" as well as "ON COM GOSUB".  Guess its just holdovers
 ES> from early basic daze.
Yeah. I had a couple of routines where I put a huge and complicated 
event handler in a sub and just had a gosub to a line that called it, 
but that does add overhead...
 ES> My use of goto and gosub within sub's is if the code in the
 ES> CASE/IF/LOOP/etc is getting a little too big.  Its easier to read
 ES> sucessive if/thens then have to wade thru an if/then a bunch of
 ES> code/then next else.  So I tend to use gosub for these, so it will be
 ES> if then/gosub/else/gosub sort of structure, and you can name your gosub
 ES> labels by what you are trying to do to make it more readable.  thats
 ES> only for stuff that others may read, my own stuff could care less (you
 ES> should see the cd-rom door code, some parts are really clean while
 ES> others it takes me a few minutes to figure out just what in the @#$%#$
 ES> i was trying to do!).
Hehe. Ever go back and replace it with a few lines of *good* code? 
 ES> btw, for easy cd-rom support i recommend allowing the file database to
 ES> be broken into "conferences" so to say, ie: allow for separate file
 ES> databases for each cd-rom disc.   merging different cd-rom discs into
 ES> same file database is a nightmare.  this way also if they change cd's
 ES> then its just a matter of taking that database out of the config and
 ES> putting the new one in.  we can discuss this more as you approach the
 ES> time when you are going to add the file area code if you want.
Oh, definetely. I was planning on having it with a separate file for 
each base.
... It only rains straight down.  God doesn't do windows.
--- PPoint 1.88
---------------