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

Actually, you would. You do not want car odometers with some knobs that allows the driver to change the value. The external API of a car odometer does not have a setter - the driver can look at the display and see the value; he cannot set it. (Day trip meters are an intermediate - they allow display, and they have a reset function, but still, the driver cannot set it to an arbitrary value). Now, the driver can drive the car, and that will cause the attribute to change, but that's not setting a value of an attribute using a set-accessor.
  • Comment on Re^4: Psychic Disconnect and Object Systems

Replies are listed 'Best First'.
Re^5: Psychic Disconnect and Object Systems
by ikegami (Patriarch) on Apr 18, 2011 at 23:11 UTC

    Now, the driver can drive the car, and that will cause the attribute to change,

    No, not without an accessor it won't. Sorry, but in Moose you don't have that form of access control. Without accessors, the car won't be able to change the odometer either. Either you have methods to change the value or you don't.

    package Car; use Moose; has odometer => ( is => 'ro' ); sub drive { my ($self, $distance) = @_; ...can't update odometer... } 1;
      Djees, then don't use Moose. Claiming odometers need setters because otherwise it cannot be implemented in Moose is just a reason to not use Moose. The AM came with the example of the odometer as "real world example of a read-only variable that cannot be recalculated".

      I don't think Detroit will start equiping odometers with knobs to set the value just because Moose cannot simulate it.

        The "problem" isn't specific to Moose. Perl itself provides even less.

        Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun
        — Larry Wall

        Mind you, the internal setter in "conventional" objects is usually direct hash access rather than a method, but that's no more private that Moose's setters.

        I don't think Detroit will start equiping odometers with knobs to set the value just because Moose cannot simulate it.

        Do you anticipate that they will define a class that will be instantiated only once?

        Or manufacture different mechanical/electrical counting mechanisms for each combination of engine, gear-train, final drive and wheel size, just so that the Odometer class getter can read directly from the volatile hardware register that counts directly in miles? Which would mean they'd need to double the number of counting mechanisms so that the register counted directly in kilometres on export models.

        Because unless the miles/kilometres attribute was incremented directly by the hardware, something has to cause it to count.


        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.