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

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.

Comment on Re^3: Language design: direct attribute access and postponed mutators (Perl Vs Python)

Replies are listed 'Best First'.
Re^4: Language design: direct attribute access and postponed mutators (Perl Vs Python) by LanX (Saint) on Sep 16, 2019 at 16:15 UTC
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}	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Language design: direct attribute access and postponed mutators (Perl Vs Python)
by LanX (Saint) on Sep 16, 2019 at 16:15 UTC

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}

[reply]
[d/l]
[select]