Borg identity [was Re: why () is () and [] is [] work in other way?]

[Ian Kelly]

On Fri, Apr 27, 2012 at 11:33 AM, Adam Skutt <askutt at gmail.com> wrote:
> On Apr 27, 12:56 pm, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:
>> On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
>> > You're going to have to explain the value of an "ID" that's not 1:1 with
>> > an object's identity, for at least the object's lifecycle, for a
>> > programmer.  If you can't come up with a useful case, then you haven't
>> > said anything of merit.
>>
>> I gave an example earlier, but you seem to have misunderstood it, so I'll
>> give more detail.
>>
>> In the Borg design pattern, every Borg instance shares state and are
>> indistinguishable, with only one exception: object identity. We can
>> distinguish two Borg instances by using "is".
>>
>> Since the whole point of the pattern is for Borg instances to be
>> indistinguishable, the existence of a way to distinguish Borg instances
>> is a flaw and may be undesirable. At least, it's exposing an
>> implementation detail which some people argue should not be exposed.
>>
>
> Then people should stop with such idiocy like the Borg pattern. It's a
> bad example from an even worse idea.

I would argue exactly the opposite.  One issue I have with the
Singleton pattern is that the very fact that a class is a singleton
(or a borg) is an implementation detail.  Shared identity exposes that
implementation detail, which I consider a flaw.  Borg, OTOH, actually
gets this right.

>> Why should the caller care whether they are dealing with a singleton
>> object or an unspecified number of Borg objects all sharing state? A
>> clever interpreter could make many Borg instances appear to be a
>> singleton. A really clever one could also make a singleton appear to be
>> many Borg instances.
>
> Trivial: to break cyclical references in a deep copy operation.

The cycle will break anyway, since there are only a finite number of
instances.  You just might end up with as many copy instances as there
were original instances in the structure.  But going back to Steven's
point here, that fact should not be important to the caller.

> I think you misunderstood me.  Define a Borg class where somehow
> identity is the same for all instances.

Why?  The whole point of Borg is to share state, not identity.  If you
really want shared identity, use a Singleton.

> Inherit from that class and
> add per-instance members.  Now, identity can't be the same for all
> instances.  As a result, you've just violated the Liskov Substituion
> Principal: code that relies on all Borg class instances having the
> same identity will fail when passed an instance of the subclass.

That has nothing to do with Borg.  That has to do with having
misguidedly defined identity to be the same for all instances.  You
wouldn't do that for a regular class.  Why force it on a Borg class?