Of course you can use the attribute directly. No one is stopping you. It'll probably work just fine. Just don't get upset when it suddenly breaks your programs when you install a new version.

Arjen

But honestly: if it's settable and gettable, what are the chances that it's not going to be a simple variable?

And a minute after posting that, I encountered this node, that answered my question one way: it's possible that a value needs to be encoded to be stored, and decoded to be retrieved. So there I have it. On the other hand, if you use a tied variable, you can do your encoding and decoding transparently and not break encapsulation...

---

We're not really tightening our belts, it just feels that way because we're getting fatter.

This will not break due to changes in $obj's interface

    my $content = $obj->content();
    $content =~ s/ome/thin/g;
    $obj->content( $content );
[download]

This might

    $obj->{content} =~ s/ome/thin/g;
[download]

The former uses the interface published by the module author. The latter relies on the internal workings of the object itself, and therefore violates the encapsulation of the object's data.

The risk that comes with the latter form (your code is now tied to the current version of Whatever::Module, and that requirement is neither enforced nor documented) just doesn't seem worth the gain of avoiding creating $content.