in reply to Re^3: Language design: direct attribute access and postponed mutators (Perl Vs Python)
in thread Language design: direct attribute access and postponed mutators (Perl Vs Python)

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

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

  • Comment on Re^4: Language design: direct attribute access and postponed mutators (Perl Vs Python)
  • Select or Download Code