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
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
In reply to Re^4: Language design: direct attribute access and postponed mutators (Perl Vs Python)
by LanX
in thread Language design: direct attribute access and postponed mutators (Perl Vs Python)
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |