Why should i use python if i can use java

[Alex Martelli]

"Don Dwiggins" <dwig at advancedmp.net> writes:
    ...
> > I've posted very extensively about it, and how I prefer 'lightweight
> > proxies' instead -- instances that have no state (but rather delegate
> > all state, and possibly all behavior, to a singly-instanced object not
    ...
> Sorry, I guess I missed those posts.

I apologize for the incomplete reference, but google surely doesn't
make it attractive to refer to their archive, what with their ugly
URI's (there may be a systematic way to simplify them, as there was
for deja, but if so then I haven't found it yet).  Anyway (please
remember that each URI is really meant to be on a single line:-)...:

http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=303263c728caff3a,
4&seekm=8s5afj0cov%40news2.newsguy.com#p

http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=90fe81cf878b00fd,
9&seekm=91d23f0jk7%40news1.newsguy.com#p

http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=e61b533755e27c16,
10&seekm=91lhdb0mb%40news1.newsguy.com#p

http://groups.google.com/groups?q=singleton+design+pattern+group:comp.lang.p
ython+author:Alex+author:Martelli&num=20&hl=en&lr=&safe=off&scoring=d&rnum=6
&ic=1&selm=934uei02u7m%40news2.newsguy.com

http://groups.google.com/groups?q=singleton+design+pattern+group:comp.lang.p
ython+author:Alex+author:Martelli&num=20&hl=en&lr=&safe=off&scoring=d&rnum=4
&ic=1&selm=9bpdsv026s8%40news1.newsguy.com

http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=6caf333bec7f9aef,
7&seekm=9c48mn020mv%40news1.newsguy.com#p

Far from exhaustive, of course, but reasonably representative
of what I've posted on this subject to this newsgroup in last
October, December, April.

I've argued elsewhere about SDP being best not used in other
different contexts (COM, C++, Java) -- the reasons are slightly
different in each case, but some (inappropriate resistance to
design-constraint changes for the SDP, for example) apply
rather widely.


> From the above, it sounds like you
> still start with an SDP-style singleton

Maybe, but not necessarily.  Since the singly-instantiated-object
and its instantiation mechanisms are not exposed, but rather are
normally internal implementation details within a single module,
it's relatively irrelevant what (if any!) mechanisms are being
used here.  I don't see, offhand, what advantages SDP would bring
in this specific case wrt more trivial just-instantiate-once
approaches to single-instantiation -- no SDP forces are really
in play.  If there was an SDP _already_ exposed from somewhere
in a library/framework that I couldn't touch, then I could hide
it behind proxies, of course -- but the SDP, if there, is just
an irrelevant minor annoyance in this case.  If the framework
or library had no single-instantiation constraint I might just
as perfectly-well instantiate just once and use the proxies in
exactly the same way.


> for the proxies to "point at", then
> add the LWP class for users to instantiate; this is essentially a Bridge,
> which fits your description of the advantages -- you allow the "state
> package" to be changed while not affecting the clients and, as you also
> describe, you can evolve the LWP separately (e.g., subclassing).  It looks
> to me as though, rather than replacing one pattern with another, you've
> created a nice composition of two patterns.  Of course, your LWPs, being
> Featherweights, could be used in other ways as well.

I disagree, because the SDP *is* all about exposing the 'single
instance' constraint to client-code -- when client code becomes
supposed to NOT see/access the singly-instantiated-object directly,
but rather only through proxies, what does SDP buy any more?

I do agree that the applicability of featherweight proxies is
very wide -- more generally, I see this as a special case of
a general technique (which Python facilitates wonderfully well,
but is well applicable elsewhere too, and *particularly* apt
in COM for example): decoupling object identity, object state, and
object behavior.  State and behavior are (mostly) still seen as
'bundled' when looked at from client-code, but objects delegate
all or part of their state to other objects 'behind the scenes'.

The unit of reuse, in such a scenario, is not the single class
but the package (aka category, cluster, area, module, ...) --
I give the classic references to, and a summary of, R. Martin's
"Reuse/Release Equivalence Principle" in the post:

http://groups.google.com/groups?q=unit+reuse+release+author:alex+author:mart
elli&num=20&hl=en&lr=&safe=off&rnum=2&ic=1&selm=9elmp4010u1%40enews2.newsguy
.com

and I don't think I can explain better than he does WHY taking
the class as "the granule of reuse" (or, of design!) is simply
inferior.  OO has long been infected with excessively class-
centered thinking, but it's been breaking free of that mindset
for a while now.  Maybe the SDP is one aspect of an excessive
reliance on "one class to bind them all"...:-).


Alex