A startup puzzle

[Albert Hofkamp]

On Thu, 2 Oct 2003 10:59:06 -0500, Edward K. Ream <edreamleo at charter.net> wrote:
>> Okay, I won't discuss, I'll just tell you that this is a recipe for
>> giving yourself a headache.
> 
> The more I think about this remark, the more I tend to agree with you.  What
> I said about not having trouble with "from leoGlobals import *" is true, and
> yet...
> 
> The problem isn't so much the present namespace pollution, the problem is
> that the technique doesn't extend well.  There comes a point at which there
> are just too many names to keep track of.  So if I were managing a group of
> programmers (thank goodness I'm not :-) I would tend to disapprove of what I
> have done.
> 
> Still, I don't see a perfect alternative.  For sure I wouldn't like to put a
> g. in front of hundreds or thousands of function calls.  I suppose that this

Afterwards, yes I agree, it is not fun to do. The lesson is thus don't
get there :-)

While writing code I don't see why adding a module-prefix is a problem,
I do that as standard coding practice. In my experience, typing is not
the problem, the design of the code, and reading code afterwards (by
others!) is the real problem.

I think the benefits of prefixing with module-names are:
- I will NEVER have to search for duplicate function-names imported from
  different modules (this alone is reason enough for me, if I can
  prevent this search once, I have already saved more time than I have
  spent typing a few characters extra).
- In my mind, I don't have a very large collection of function names
  without ordering, I have a collection of modules, and within modules a
  collection of function names, ie in my mind, I use the module structure.
  This is a better scalable structure for remembering functions and what
  they do.
- The module name helps understanding what the code is doing.
  ie timer.start() is much more helpful than start()
- I have a clear seperation between function calls to my own code and
  other people's code, ie the system/module boundaries are very clearly
  visible.

However, if you think these benefits do not exist, or are too small,
then by all means, use the "from .... import *" form.


Albert
-- 
Unlike popular belief, the .doc format is not an open publically available format.