mascip

If you make the assumption that all access to attributes is via accessor methods, and nobody is going to sneakily look at $instance->{"attr"}, then immutability is not that difficult to achieve.

Firstly, make sure all attributes are declared as is => "ro". That's half the battle already; attributes which are strings, numbers, booleans, etc will now be reasonably protected.

The remaining gap is references. Although the reference itself will be read-only, the thing being referred to (probably an array or hash) is still mutable. For example, for a read-only attribute which is an arrayref, we can still do this:

push @{ $instance->attr }, @more_things;

Note that this is exactly where the "always in a valid state" problem that chromatic mentions comes in. Perhaps we validated that attr was an arrayref of integers in the constructor; that push statement could be adding any old data onto the array.

The Perl internals have the ability to mark an array or hash as immutable, though this is not really documented. Const::Fast is one module that exposes this functionality, though the API of Const::Fast is not especially convenient for applying read-onlyness to Moose/Moo object attributes. Sub::Trigger::Lock is a module I wrote that is perhaps a little more convenient for use with object attributes. (I perhaps need to better document the gotcha that triggers aren't executed when an attribute value is provided by the default/builder sub.)

Another approach would be to simply not have any attributes which are hashrefs or arrayrefs. Instead, make the attributes be some kind of blessed set/collection/bag objects which provide their own accessor methods. List::Objects::WithUtils is a good place to start if you want to pursue this approach. List::Objects::Types even provides some nice coercions to List::Objects::WithUtils objects from plain old arrayrefs and hashrefs.

I don't think cloning is necessarily the best way to approach this. Yes, it's potentially a pretty thorough way to prevent people from tampering, but it has its own set of problems.

If all objects are plain old blessed hashrefs, cloning everything seems a simple enough proposition. Cloning $o is really just $clone = bless({%$o}, ref($o)). However, given that objects (even hashref-based ones) may store some of their attributes inside-out, this isn't a generic solution - it requires some co-operation from the object; it must provide some kind of $o->clone method for you to call.

Co-operative immutability is perhaps a better solution. If I have an attribute which takes DateTime objects, and it's documented as read-only, then I probably don't want you calling mutator methods on it. Perhaps you technically can, but I'd rather you didn't, the same way I'd rather you didn't access my attributes like $o->{"attr"}.

There are styles of programming that encourage people to co-operate. In your example where you create a DateTime object, pass it to my constructor, and then manipulate your original DateTime object, that could be combated by documenting that my constructor accepts an ISO-8601-formatted datetime string, and then coercing it to a DateTime object internally.

In your example of $object->attribute->some_mutator(), if $object->attribute just returned a clone of the attribute, yes, it would mean that $object has been made safe from mutation, but it also means that the call to some_mutator() has silently succeeded, but effectively probably done nothing, which leads to a counter-intuitive interface. I'd rather that call threw an exception. And if an exception is not a possibility, then I'd rather it just properly succeeded, mutating the object, but in documentation discourage callers from doing this sort of thing. (See also: the Law of Demeter, which if followed would probably forbid such a method call.)

Immutable instances require "buy-in" from across the entire application. Yes, I can write a class in such a way that it encourages immutable usage (e.g. making accessors read-only). However, this class is only a small part of the jigsaw that makes up the entire application. Perhaps some of the other classes in the application (like DateTime) might have mutable instances - the solution is to just agree to not call the methods that mutate instances - especially not on objects which might have other objects pointing to them and thus result in action at a distance. (If I create a DateTime object in a method, and don't pass it to anybody else, then I can probably safely call mutators on it within the privacy of my own homeHHHH lexical scope.)

I wonder what you are looking for is something like how DBI works (on the inside).

For example when you prepare a statement you get a new copy of an 'Statement' object, or handle to use DBI-ish, while the original statement object stays unchanged from when you start.

Is this what you are looking for??

DBI is actually an example of where mutable objects are perfectly sensible: as iterators.

Immutable objects are great because they are easier to reason about, reduce the possibilities for action at a distance, and make testing simpler. But they are not the perfect fit for every problem. Sometimes you need to be prepared to forego the benefits of immutable objects, in favour of coming up with a class design that makes the most sense for the type of data and processes you're modelling.