I think I've read it in pretty every OO tutorial I've seen, including PBP and Damian's OO book.

The explanation seemed very obvious to me, since one is directly accessing the internal implementation of a blessed hash.

1. the internal implementation is not necessarily a hash, one can bless any ref
2. you can't change the internals anymore once they are exposed *

> Also, DBI does that as well (but uses tie) behind the curtain.

Uhm, I ignored this till now ... but DBI is a very byzantine module anyway.

But you convinced me to s/uncommon/oldfashioned/ , thanks :)

*) OK you can tie the hash/data structure, but this will slow down all internal access to any $self->{attribute}

I'm not saying that the approach of directly setting/changing data is good design, but it's neither oldfashioned nor uncommon.

The Moo* "object" builders encourage data hiding, and PBP and Damian's OO book go to even more extremes. Data hiding / data encapsulation certainly are good approaches especially if you are working with a large codebase where different people make changes.

But none of this warrants "oldfashioned" or "uncommon" as adjective. Maybe "unwise" or simply "direct" instead of "indirect" or "encapsulated" are the better adjectives.

But all approaches that add another layer of indirection between the intention to set a value and the hash access make things slower.

TIMTOWTDI.

I think as long as an $obj->{attribute} is documented as part of the API it's fine to use it. Who am I to worry about the maintenance of a foreign module like DBI.

from DBI docs:

$h->{AttributeName} = ...;    # set/write
... = $h->{AttributeName};    # get/read
[download]

But I'm open to hear from other CPAN modules besides DBI which "decapsulate" their internals.

I have colleagues who thought doing this with undocumented attributes which were only set in the constructor is fine. I disagree strongly.

That's like monkey patching a module or changing parts of a laptop, one shouldn't be surprised about loss of warranty.

> But all approaches that add another layer of indirection between the intention to set a value and the hash access make things slower.

Noteworthy that DBI is adding such a layer:

Attempting to set or get the value of an unknown attribute generates a warning

This will hardly be fast.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

I'm not sure where you get this "very uncommon in Perl" from.

While I have seen it - and used it - in methods of a class, I have very rarely seen it done in users of a class.

(I can't say about Python code as I have done very little Python coding.)