Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re: Re: How to measure Perl skills?

by hardburn (Abbot)
on Mar 23, 2004 at 14:18 UTC ( #339006=note: print w/replies, xml ) Need Help??

in reply to Re: How to measure Perl skills?
in thread How to measure Perl skills?

encapsulation of class attributes (if you care about that sort of thing)

You should care. Otherwise, why are you bothering with OO at all?

Automating get/set methods with AUTOLOAD

No, that breaks encapsulation. AUTOLOAD isn't the best way to do that, anyway. Putting sub refs directly into the symbol table at runtime is much faster.

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re^3: (~OT) How to measure Perl skills?
by QM (Parson) on Mar 24, 2004 at 23:33 UTC
    A bit OT, but I think you've given a simplified answer to a simplified question.

    I'm not sure how AUTOLOAD breaks encapsulation, as the AUTOLOAD code can decide what is allowed and what isn't [die "Horribly" comes to mind]. And AUTOLOAD only needs to be called the first time an unregistered method is requested -- the symbol table hockey will avoid future AUTOLOAD calls on that method, at least.

    But maybe you meant to just generate all of the sub refs at initialization, so all the methods didn't need explicit coding, just a method factory? Autogenerating all method code is probably faster than the AUTOLOAD runtime on just one method (for some values of all method code).

    On further reflection, it sounds like we might be in violent agreement.

    Quantum Mechanics: The dreams stuff is made of

      This is a nit but anytime the symbol table is altered the method cache table is invalidated so all your calls to $obj->foo have to do the full @ISA check again as well. That makes it nice to do symbol table updates only as needed or preferrably before the cache is going to be desired.
        There's a method cache table??? You [or I, in this case] learn something new everyday.

        Quantum Mechanics: The dreams stuff is made of

      If you're using AUTOLOAD instead of methods like this:

      sub foo { my $self = shift; $self->{foo} = shift if @_; $self->{foo}; }

      Then you're breaking encapsulation. You were better off just providing a hash and a few subroutines to work on it. In a well-designed class heriachracy, you will need very few accessors/mutators (i.e., methods that directly access the internal attributes of the object). OOP purists will tell you that you need none at all, but I find that in practical code, you'll have a hard time factoring out the last few.

      (I suspect the reason for this is a diminishing-returns thing. You can theoretically get rid of all accessors and mutators, but eventually the work required to do so just isn't worth it.)

      This isn't the only use of AUTOLOAD, but it is almost certainly the most common.

      Ignoring OO purity for the moment, AUTOLOAD still isn't the best way to get accessors/mutators, provided you know what fields you want to work with in advance (if you don't, then you'll probably have to use AUTOLOAD). Example:

      foreach my $field (qw/ foo bar baz /) { no strict 'refs'; *$field = sub { my $self = shift; $self->{$field} = shift if @_; $self->{$field}; }; }

      This gives you a little overhead when the module is loaded. It has the advantage of being as fast as a regular method lookup, in addition to saving memory (because it's making a reference to the same subroutine each time).

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://339006]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (4)
As of 2018-05-28 02:24 GMT
Find Nodes?
    Voting Booth?