in reply to Re^2: Psychic Disconnect and Object Systems
in thread Psychic Disconnect and Object Systems

Attributes are per-object.

If an instance attribute is to ever have any value, then it is at best: write-once.

And it is conceivable that a factory constructor could derive from different base classes to provide different constant attributes.

Constants are per-process.

Actually, Perl's constants are per-package rather than per process. And it certainly isn't inconceivable that they could be implemented to be block scoped as many of the newer pragmas are.

And as I understand it, it would be completely possible to have per-instance constants with Perl 6 using Roles. Maybe even in Perl 5 with Perl6::Roles

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.
  • Comment on Re^3: Psychic Disconnect and Object Systems

Replies are listed 'Best First'.
Re^4: Psychic Disconnect and Object Systems
by ikegami (Patriarch) on Apr 16, 2011 at 00:14 UTC

    If an instance attribute is to ever have any value, then it is at best: write-once.

    I've never heard people say constants are write-once rather than read-only, yet the same applies to them.

    Yes, I did say "read-only" attributes are «more "write-once" than "read-only"» earlier, but I now think that was a mistake.

    Actually, Perl's constants are per-package rather than per process.

    For each definition of an attribute, there is one value per object.

    For each definition of a constant, there is one value per processinterpreter.

    I have no idea what you think is per package.

[reply]
      I've never heard people say constants are write-once rather than read-only, yet the same applies to them.

      Oh dear. You've moved into let's defend the indefensible mode again.

      Constants are 'set' at compile time. Write-once attributes are assigned at runtime. That is a very clear distinction.

      Not as clear as in a compiled language in as much as they are not loaded from the process image into hardware-protected read-only memory segments. But sufficiently intractable to even deliberate meddling; and with sufficient performance benefits; to make the distinction obvious.

      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]

        Constants are 'set' when they are constructed. Read-only attributes are set at construction time. In neither case can you choose to write later.

        Are you gonna start calling read-only memory pages write-once too? What about constant parameters and constant variables in C? I'd like you to try to tell the author of Readonly that his module name is indefensible. (Why do you always have to be such a jerk?) All four are constructed at run-time.

        "Write-once" is used to describe something whose initial state can be changed only only once (e.g. some memory chips).

        "Read-only" is used to describe something that can no longer be changed. It obviously does not preclude the thing from being initialised at construction (e.g. ROM chips, constants, and object attributes).

[reply]
      At least C++ has an ISO standard with precisely defined nomenclature. Most people don't use it that carefully, but the formaism can be trotted out and used when necessary.
[reply]
        Out of curiosity, does it call j and k read-only or write-once?
[reply]

In Section Seekers of Perl Wisdom