"Rainer Deyke" <root at rainerdeyke.com> wrote in message
news:a8_D6.60935$J%5.20446933 at news2.rdc2.tx.home.com...
[snip]
> Just as I can use the term "command" to refer something different from the
> Command design pattern (note different capitalization), I generally use
the
> word singleton to refer to something that is not necessarily implemented
> through the Singleton design pattern.
Makes sense, which is why I asked very specifically, when you
mentioned singletons, whether you had examples where you
found the Singleton design pattern best. Apparently your
answer was not to the question I asked.
> > That there exist design situations where a single copy of a
> > certain "state" is desirable, is hardly in question -- that IS
> > a force that comes up again and again. The issue is how to
> > best resolve it, and the other forces that accompany it in
> > various use cases.
>
> What generic word would you use to refer to an object that encapsulates
> program-wide unique state?
As it happens, in my favourite (free-time) application area, I had
better avoid naming such object 'singletons' any more than I could
name others 'doubles', 'diamonds' or 'squeezes' -- these are all
important words and concepts in contract bridge (and, some of
them, in other games, too -- but bridge is my field).
Apart from application areas -- in maths, a singleton is a set with
a single member... it's not that member (and the distinction is
important). If one looks at a _class_ as somehow equivalent to
the set of its instances, then calling the *class* 'a singleton' may
make sense, but calling the *instance* 'a singleton' would not.
> > > Python is more than complex enough for me.
> >
> > So how would __module__ and __istance__ and __function__
> > and all other such additions REDUCE its complexity that
> > you perceive?
>
> See above for my Grand Unification Scheme. '__module__', at least, makes
> 'global' redundant. As I stated in another thread, sometimes you need to
> add new features before you can remove old ones. '__module__' seems
simpler
> to me than the one-and-only non-executable statement in Python.
If modifying globals from inside a function is meant to be a rare
thing, then I agree with you that using "__module__.x=y" &c for
such modifications (rather than "global x" followed by "x=y") may
be perfectly acceptable. The global statement does cater better
for a style in which such "rebinding of globals" from within a
function come "in clusters" -- many functions may not need to
do any such binding, but those that do may need to bind more
than one global or at least bind a global in several places, e.g.
def example():
global x,y,z
if x>0:
x=y=z=23
elif y<z:
x=y=z=34
is already substantially more readable than an equivalent
using __module__ six times.
'global' does (in my modest experience) give some problem
to some students, typically coming out as expressions of
astonisment that some equivalent of
x=23
def f():
print x
x=45
print x
fails. This empirical observation does lend some support to
your thesis. However, I wonder if having the 'fix' be changing
the assignment to "__module__.x=45", rather than inserting
a "global x", would do all that much good in this regard.
Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4