Structuring larger applications - ideas

[John Roth]

"Iwan Vosloo" <iv at lantic.net> wrote in message 
news:1116259236.861818.127170 at g14g2000cwa.googlegroups.com...
>
> I know my foreign (to python) one class per module idea is what makes
> life more difficult for me here.  And there is an argument to be made
> out that it is a stupid remnant I stick to from having used it in other
> programming languages (do I have to admit C++ in my background?)  Two
> small examples of where it it useful for me:  my development
> environment is run by make to a large extent.  Many standard UNIX tools
> have the intelligence to deal with filenames, and if you know a file
> corresponds to a class, you have a lot more info available in your
> makefile.

Have you looked at using scons (http://www.scons.org/) instead
of make?

> Also, if I use my version control software (currently gnu
> arch) to see what's changed, for example, I get a list of changes files
> which again gives me more info because I know a file corresponds to a
> class.

> So, I can do a number of such small things using that convention that
> works well with standard old UNIX tools.  And I find that valuable.

Sometimes little conveniences lead to great big tar pits.

> As for the dependencies- I'm trying to keep the specification of them
> simple.  From a design point of view, it makes sense to me to only
> specify ONCE that largeish-collection-of-classes-A depends on
> largeish-collection-of-classes-B.  As another simple small example: say
> I change the name of large-collection-of-classes-B - this way I only
> need to do it once, else I need to grep and sed all over in order to do
> it.
>
> It just feels cleaner and easier.

This is what packages are for. As far as refactoring package alignments,
a little bit of scripting goes a long way. Sometimes trying to make an
existing tool do something that it's not really right for distorts the 
entire
process, rather than simplifies it.

John Roth

>
> -i
>