* Steven D'Aprano:
On Sun, 07 Feb 2010 01:34:14 +0000, bartc wrote:
For a real-world example, it means instead of having a room with a
light-switch in it, if I *know* I want the light on or off, I should
have two rooms: one with the light permanently on, and one with it
permanently off, and just walk into the right one.
I don't think you can apply real-world analogies to software in that way.
They're too different.
Think of the objections to having two rooms, one permanently lit up, the
other permanently not:
(1) Having two rooms is expensive and wasteful of physical space, which
is in short supply.
(2) You typically use rooms for storing things (furniture and smaller
objects), having two rooms mean you would need to clone every object
inside it and somehow keep them in perfect synchronisation.
(3) the light that is always on will use electricity 24 hours a day,
regardless of whether you are inside it or not.
But none of those objections apply to functions:
(1) Functions are cheap and live in memory, which is not in short supply
unless you're programming for an embedded device.
(1a) Even if you are programming in a device that is short of memory, the
overhead of a second function is minimal. There's little difference
between:
def func(flag):
if flag:
blockA
else:
blockB
and
def funcA():
blockA
def funcB():
blockB
for any non-trivial code blocks, particularly if any common code is
factored out into another function which you call.
(2) Functions aren't typically used for storage, and when they need
external data, it is easy to have them access a common data store.
(3) Functions don't use CPU cycles just by existing.
I agree with your reasoning :-), but it's not either/or.
Consider, sometimes one wants to do
switch.off()
and sometimes one wants to do
original_switch_state = switch.state()
switch.off()
# ... Do things that are best done in utter darkness.
switch.set_state( original_switch_state )
E.g. the "switch" might be the enabled/disabled state of some GUI widget.
So IMHO it depends.
Sometimes one wants both kinds of "protocols".
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
