in reply to The fallacy of the *requirement* for read-only instance variables.

Consider an unique object id. It need not be expensive to calculate and it doesn't matter in the slightest how often it will be used. It might not be used by the object itself. But it must be immutable once defined.

For instance: a "dogs" class; the unique id is a sequential integer. When I instantiate Scruffy, nobody else knows or cares how many dog objects I have created in the past, so the value must come from the class itself. The pet_store class will need the id to complete the sale, the obedience_school class wants to know who will be showing up, the vet class needs to keep track of rabies shots, and the pet_cemetery class will want to know who's in crypt #53. Or, none of these if I'm the breeder, own a chain disreputable restaurants and just need to keep track of tonight's special.

  • Comment on Re: The fallacy of the *requirement* for read-only instance variables.

Replies are listed 'Best First'.
Re^2: The fallacy of the *requirement* for read-only instance variables.
by GotToBTru (Prior) on Apr 20, 2011 at 06:47 UTC

    Okay, I added a comment on the root of this thread after it had gone on a while. Let me clarify a bit.

    The premise of this thread was "under what conditions is it correct to use a read-only instance variable?" You said there were 3 conditions:
    1. The value stored in the ROIA must be expensive to calculate.
    2. It must be required multiple times.
    3. It must be required both internally to the instance; and externally to it.

    I'm suggesting that a unique id would be a counter example. Does it need to be read-only? Absolutely. The unique id is a property of a particular instance of a class that makes it distinguishable from all other instances. Read-only is relative of course. The object itself must be able to modify the value but nothing external should be able to. The value would be set at the time the object is instantiated. Is an instance variable an appropriate place to store this? Absolutely. The value must reside in the instance of the object. Two different instances will have different unique ids. And there is no need to supply a method, the values are static once set. Simply inspect the value.

    I used the example of a "dog" class. It is easy to imagine another example: breed. The breed of dog would be set in the object at the time of creation and won't ever change during the life of the object.

    The details of setting the unique id need not be expensive at all (increment a class variable by 1 for instance), but only the class itself has the knowledge to set it. Breed would probably be passed as a parameter to the constructor but again, not an expensive calculation any way you look at it. Also, the use of a read-only instance variable is dictated by the application - a value that can't be changed and is tightly associated with the instantiated object. I don't see how it possibly matters how many times it is used.

    I don't see myself how a unique id would be used internally but I haven't worked out the implementation details. I mention this only for completeness. It was the third point and I can't speak to it.

    I hope this clears up what I was saying.

[reply]

      And my response remains the same.

      Outside of the myopia of a for-arguments-sake-only, do-nothing-and-no-details example, this does not stand up to scrutiny.

      For your example of dogs, which live longer than the program runs, your unique ids have to persist longer than one run of the program, else they serve no purpose. The object handle is already a unique identifier for programmic purposes.

      And once you persist your objects (with identifiers) to disk, you need to be able to re-constitute them by instantiating instances that will be given their ids as read from disk. But, you also need to be able to instantiate new instances which will get their ID from the class.

      Now you need to be able to set the ID to be either then next increment of the monotonically rising counter; or set it to the value read back from disk.

      Therefore, you need a setter. Even if that setter is programmed to only work once per instance. (Ie. Write-once, not Read-only)

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        Considering that nothing comes from nothing, everything that has ever come into being had a "setter" of some type. Read-only doesn't exist, by that definition.

        As far as I can see, persistence makes the case for the applicability of a ROIA in the role of unique id. 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. We don't need the horsepower or overhead of a method, there is nothing to calculate. The value rightly belongs to the object itself. Why not us an instance variable that can't be changed? Actually, if we are willing to shorten our attention span slightly, the unique id in the reconstituted object is an example of read-only.

        What details are missing? 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. Do nothing? I think not.

        How do you implement unique ids in objects without using an ROIA?

[reply]
Re^2: The fallacy of the *requirement* for read-only instance variables.
by BrowserUk (Patriarch) on Apr 19, 2011 at 21:31 UTC

    Okay, but unless your program is going to run for the life of the dog, and the combined lives of all the dog 'registered', you are going to have store that unique id somewhere between runs of this program. And accessible to other programs that might need to deal with it. And that means that on subsequent runs you are going to have to read it back from some persistent storage and then set it.

    Unless you can set it (at least once) it never has a value. And the only way to set it without using a setter, is to initialise it using a constant. Are you going to hard code all your unique ids into (all) your program(s)?

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Meditations