Borg Pattern Class usable from other classes?

[Paul Winkler]

On Sat, 13 Oct 2001 10:53:26 +0200, Alex Martelli <aleax at aleax.it> wrote:
>Paul Winkler wrote:
>
>> On Fri, 12 Oct 2001 10:27:23 +0200, Alex Martelli <aleax at aleax.it> wrote:
>>>Highlander for the DP, and Borg for the non-pattern which I
>>>posted and D. Ascher named, seem much more appropriate names,
>>>as the connection to science fiction movies/TV series is sharp
>>>and pleasingly anti-parallel.
>> 
>> AFAIKT, Borg is the same as Monostate which seems to have been around
>> for a couple years:
>> 
>> http://www.ddj.com/articles/1998/9809/9809a/9809as2.htm
>> 
>> At least, the Consequences are identical:
>> """
>>     * Multiple local instantiations but always with only a single state.
>>     * Persistent object state in the absence of any instantiations.
>>     * Familiar syntax. Does not require an accessor function as with
>>       Singleton objects.
>> """
>> 
>> Borg is an OK name but Monostate is a little more obvious to those of
>> us who don't know much about Star Trek (yes, we exist).
>
>Borg and Monostate (attempt to) solve the same forces.  However, they do so 
>in different languages.  *Language-appropriateness* of patterns is often 
>ignored, even though the Gang of 4 mention it quite well right in Chapter 1,
>exemplifying with Visitor, which would be pretty silly in a language with 
>multiple dispatch.  Similarly, "just keep all data static" (which I had 
>first met, without a catchy name, in the context of C++) is OK for C++ or 
>Java, but not for Python, where you may want to allow, for example:
>        theobj.acount += 1

Thanks for the reply.

I must admit I'm confused. I haven't read GoF yet; I've just finished
a first reading of "Design Patterns Explained". The impression I have
(perhaps incorrectly?) is that patterns are relatively
language-independent descriptions of recurring solutions (which may
not be useful in all languages), and as such, the implementation can
be adapted to the idioms of the language in question. So by this
understanding, if I wanted to achieve the above-stated *consequences*
of Monostate in Python, I'd look at Borg and say "this should do the
job".

So I see "keep it static" as a language-dependent implementation
detail of Monostate.

I guess what it boils down to is this: If Python gives us the ability
to create a shared-state object whose attributes are easier to set
than a C++/Java Monostate, does that mean we have to call the pattern
by another name?  Does Monostate mandate that attributes must only be
modified or set via methods?  It didn't say anything like that in the
(short) descriptions of Monostate I've found online, therefore I
assumed the pattern was neutral on this issue.

>> BTW, are there any "gotchas" with Borg/Monostate in a multi-threaded
>> context? Singleton requires extra care, leading to the "Double-checked
>> Locking" pattern which apparently has been found not to work in
>> Java. Any such snags for Borg? I can't think of any, but I've only
>> really toyed with threads.
>
>If two Borg instances are created in separate threads, they still access 
>the same state-data, so you get the joys of dealing with whatever 
>synchronization issues.

Oh, blarg - I wasn't thinking properly. Of course it's a problem...

if Borg().foo < bar: Borg().foo += 1

Result could be unexpected if two threads do this "at once".

Still digesting the rest of your reply. Damn, threads are weird.

-- PW