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

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

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 :)

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

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

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

Replies are listed 'Best First'.
Re^3: Language design: direct attribute access and postponed mutators (Perl Vs Python)
by Corion (Patriarch) on Sep 16, 2019 at 07:45 UTC

    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.

[reply]
      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]

In Section Meditations