Kent Johnson wrote:
Dave S wrote:
Separate modules is good. Separate directories for anything
other than big programs (say 20 or more files?) is more hassle
than its worth. The files are better kept in a single directory
IMHO. The exception being modules designed for reuse...
It just makes life sim
Alan Gauld wrote:
1) batch oriented - each step of the process produces its own
output file or data structure and this gets picked up by the
next stage. Tis usually involved processing data in chunks
- writing the first dump after every 10th set of input say.
I see your point, like a static
> >1) batch oriented - each step of the process produces its own
> >output file or data structure and this gets picked up by the
> >next stage. Tis usually involved processing data in chunks
> >- writing the first dump after every 10th set of input say.
> >
> I see your point, like a static chain,
> For what it's worth, it seems to me to be perfectly normal to have
> classes that are only ever intended to have a single instance. For
> example, you're never likely to need more than one HTML parser, and
> yet htmllib.HTMLParser is a class...
That's true but the argument for a class in that c
Dave S wrote:
Separate modules is good. Separate directories for anything
other than big programs (say 20 or more files?) is more hassle
than its worth. The files are better kept in a single directory
IMHO. The exception being modules designed for reuse...
It just makes life simpler!
Ive tried t
Jeff Shannon wrote:
Dave S wrote:
Kent Johnson wrote:
Why do you say this is 'cheaty'? A class is basically a collection
of data (state) and functions to operate on that state.
Sorry for the delay, real world work got in the way ...
Well I understand classes to be used when multiple instances are
Sorry for the delay, real world work took me away ...
everything was global, how you guys handle a modern structured
language
Don't worry this is one of the hardest bad habits to break.
You are not alone. The easiest way is to just pass the data
from function to function in the function pa
Dave S wrote:
Kent Johnson wrote:
Why do you say this is 'cheaty'? A class is basically a collection of
data (state) and functions to operate on that state.
Sorry for the delay, real world work got in the way ...
Well I understand classes to be used when multiple instances are
required, I will o
Kent Johnson wrote:
Dave S wrote:
Dave S wrote:
The 'remembering where is was' seems a continuous stumbling block
for me. I have though of coding each module as a class but this
seems like a cheat. I could declare copious globals, this seems
messy, I could define each module as a thread & get th
> Having written this email, it has put my thoughts in order, though
it
> seems a bit cheaty, wouldn't defining all modules that have to
remember
> their internal state as classes be the best bet ?
Its one solution certainly, creeate objects and the objects carry
their state with them. But the pro
> everything was global, how you guys handle a modern structured
> language
Don't worry this is one of the hardest bad habits to break.
You are not alone. The easiest way is to just pass the data
from function to function in the function parameters. Its not
at all unusual for functions to have
Dave S wrote:
Dave S wrote:
The 'remembering where is was' seems a continuous stumbling block for
me. I have though of coding each module as a class but this seems like
a cheat. I could declare copious globals, this seems messy, I could
define each module as a thread & get them talking via queue
Dave S wrote:
Im sorry to bang on about Python structure, but I do struggle with it,
having in the past got into very bad habits with loads of BASIC where
everything was global, and Forth, and hand coded 8031, 8051, 6502
I cant get my head round how you guys handle a modern structured
lang
13 matches
Mail list logo
