When as stored object is reconstituted, will the object handle be exactly the same value as it was before? Obviously not, handles must be recycled or we would have run out by now. Therefore it could not serve this purpose.

Hm. You now appear to be saying that your unique ids are not persisted with the objects. And therefore each time the dog objects are reloaded, the UID they get depends entirely upon the order they get loaded. Just the next sequential integer as issued by (say) a class method that starts counting at 0 or 1 with each new run of the program. At least that is the only interpretation I can put on the quote above?

Assuming that is what you mean, then what happens when the obedience_school, vet or pet_cemetery ring up and quote the UID you gave them yesterday? You are now talking about a completely different animal.

Or when business picks up a bit and your single office computer becomes a bottle neck, and you add a second. But between the part-timer coming in an starting the second system, you've added a couple over-night new-arrivals to the DB. Now the second system has completely different UIDs for each dog to the first system.

What on earth use is that?

I think we all understand the concept of a unique id and how they are used. Enough to know they are fundamental to relational databases, serializations schemes, object handles, etc.

And therein lies the rub I think. In the abstract, you think that this unique id you are describing makes sense. But in reality it doesn't.

For a UID to make sense in the real world, it needs to persist to be unique at least as long as the dog does. And actually longer. In the real world, forever. Like company employee IDs, and pet RFID chips, and social security numbers and NIC numbers etc. such numbers are never reused.

The only IDs I can think that fit the pattern of usage you are suggesting, are the IDs used to index into Inside-Out class attribute hashes as seen for example in Class::Std. But it defines the class ID method as:BEGIN { *ID = \&Scalar::Util::refaddr; }. In other words it uses the object reference as the UID. (Quite why they moved away from using the stringified object reference as Abigail did originally, I'm not sure?)

But the point here is that this is, and must be, a private attribute.. There must be no setters or getters. Because if you start sharing this ID with other classes--for instance, to allow composition--then whether stored and shared as a number (refaddr) or stringified, it is taken out of Perl's visibility.

Which means that the original object can be destroyed without the sharing class knowing, and any attempt to access the object thereafter will variously:

• not find it.

  Your composite object suddenly finds bits of itself have 'gone away'.

• Crash.

  Someone, somewhere attempts to reconstitute the object reference from the number and discovers that the address has been freed back to the OS or worse, reallocated for some completely different use.

• Been reused for an entirely different instance.

  Perhaps the most insidious of all. Sharing classes continue to 'work' and use the instance, it just isn't the instance they originally composed.

Now, I'm not saying there is never a valid use for ROIAs. Indeed, I didn't say that originally: "This combination of circumstances are far, far rarer than the prominence ROIAs are given in texts, documentation and existing codebases would suggest. And in many cases, maybe even most cases of existing usage, that combination of properties is a strong indication of bad OO."

I am saying that if it is important to the construction and/or running of a class to have a per-instance value that is set once at construction by the class and thereafter never changed (what I prefer to refer to as write-once), then that value must also be private to the class.

The reason you want this to be read-only is because it becomes important to the class that it alone manages it. But as soon as you provide external access to it, someone, somewhere is going to store that value and try and re-use it later. Perhaps after you've decided to throw it away or reuse it.

And that bring me neatly to the strongest objection. What is the purpose of the caller having visibility of this value? What are they going to do with it? Presumably, they can see it so that they can use it. But how are they going to use it?

1. Call an instance method and pass the ID back to you?

   Why? If the have an instance handle on which to call a method, what purpose is there in them passing you the ID when it only identifies the same thing as the object handle they have, and which the method gets past anyway. And from which you can look up the ID internally anyway.

2. Call a class method with the ID to retrieve an instance handle?

   To what end? Why don't they just store the instance handle instead?

   And what happens if they (accidentally or deliberately) corrupt the ID they read from you and pass back a different number? With luck it will be corrupted to an id that has never been allocated and you can tell them to go get stuffed.

   But with monotonic numbers, a simple decrement is likely to give them access to an instance they should never have access to with who knows what consequences.

May be there is a good use for ROIAs that I'm just not seeing. What I can say is that none of the examples offered so far, and none of those I've seen described, stand up to scrutiny.