Methods vs. functions

[bdbaddog]

This issue was originally created at: 2002-08-16 12:30:41.
This issue was reported by: aroach.
aroach said at 2002-08-16 12:30:41

I find it difficult to keep track of whether a
particular thing is a global function provided by SCons
or a method of Environment. It also seems that there is
no consistent rule for this. For example Precious would
seem to be environment neutral since it just tells
SCons not to delete a file before building it, and yet
it is a method of Environment. In addition I've had
some trouble explaining to people why they need to
create an Environment instance just to do something
simple.

I propose the following:

1. every global function should have a corresponding
   Environment method that just calls the global function.
2. every Environment method should have a corresponding
   global function that calls the Environment method on
   some default unamed environment (or maybe the default
   environment is made available using the name "env").

For example this would allow a SConstruct file to
contain just:

Program('foo', 'foo.c')

Man that's cool!

Also this would work:

env = Environment()
foo = env.Program('foo', 'foo.c')
env.Default(foo)

aroach said at 2002-08-16 12:44:17

After a little more thought, maybe #1 isn't such a good
idea, because it might give people the impression that
certain functions are environment specific rather than
global. For example:

env1.SetCommandHandler(foo)
env2.SetCommandHandler(bar)

makes me think that foo will be used for commands executed
by env1 and bar for env2, which is not the case.

I still whole heartedly endorse #2.

stevenknight said at 2003-10-17 19:26:15

Fixed for 0.93.

issues@scons said at 2003-10-17 19:26:15

Converted from SourceForge tracker item 596232