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

[Adam Skutt]

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.

> 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.

> John's argument is that Python should raise an exception if you compare
> "2 is 2", or for that matter "3579 is 3579", which is foolish.

> >> identities. The Borg design pattern, for example, would be an excellent
> >> candidate for ID:identity being treated as many-to-one.
>
> > How would inheritance work if I did that?
>
> You don't inherit from Borg instances, and instances inherit from their
> class the same as any other instance.

I think you misunderstood me.  Define a Borg class where somehow
identity is the same for all instances.  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.

It's impossible to combine identities and not violate LSP, unless you
forbid subclasses.  Your idea violates one of the most fundamental
tenants of object-oriented programming.  This is because object
identity is one of the fundamental consequences of object-oriented
programming.  You can't do away with it, and any attempt to do so
really just suggests that you don't understand OOP at all.

Adam