"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:9bq9ir01lad at news1.newsguy.com...
> "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.
To answer your question, I have yet to use either the Singleton pattern or
the Flyweight pattern exactly as described in Design Patterns. To
enapsulate global state I use global variables (or, in C++, static variables
of functions). Sometimes these variables require a new class, usually they
don't.
> > 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.
This does not answer my question.
> > 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.
The same argument could apply to methods:
def example(self):
if self.x > 0:
self.x = self.y = self.z = 23
elif self.y < self.z:
self.x = self.y = self.z = 34
vs.
def example(self):
instance x, y, z
if x > 0:
x = y = z = 23
elif y < z:
x = y = z = 34
I find the former quite readable, but that's just me. If you recall, I was
arguing for consistency, not necessarily for any specific approach.
--
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
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