in reply to RFC: The Poor Man's Accessor Filter

So what's my faux pas?

Using a source filter.

There are many good reasons why source filters aren't recommended, for example because they can lead to bugs that are very hard to find, and that you can't combine multiple source filters in general.

Why not use Class::InsideOut or Object::Inside for it? If you must do it yourself, write a subroutine that installs the handler in the caller's namespace - might be a few more lines, but much more robust than a source filter.

  • Comment on Re: RFC: The Poor Man's Accessor Filter

Replies are listed 'Best First'.
Re^2: RFC: The Poor Man's Accessor Filter
by JavaFan (Canon) on Oct 08, 2008 at 15:55 UTC
    If you must do it yourself, write a subroutine that installs the handler in the caller's namespace - might be a few more lines, but much more robust than a source filter.

    That won't work (in pure Perl) in traditional inside out objects, as the attributes are stored in lexical variables. No code from other files is able to touch it.

    But there are other solutions. Accessors are typically very similar, one could generate them with an editor macro.

      Editor macros would be a perfect fix for my COBOL Fingers. Thank you for that suggestion, which should have been obvious to me.

      At the same time, there's still that Perlish allure of simplifying code which ought to look simple. My macros relieve my fingers, but my eyes still have to grok a lot of line noise.
        At the same time, there's still that Perlish allure of simplifying code which ought to look simple.

        But simply looking code doesn't exclude repetition, or not using modules. A simple accessor, for instance the one found the OPs post, remains simple, even if repeated several times with just a change in the name of a variable. The human mind is geared towards recognizing patterns - it won't get confused, and a pattern is the opposite of line noise. OTOH, having a module generating the accessor for you will always leave some people with the question what really goes on in the accessor, and they'll have to look at, and understand, the code generating code in the module.

Re^2: RFC: The Poor Man's Accessor Filter
by rje (Deacon) on Oct 08, 2008 at 16:28 UTC
    Ah, I didn't realize source filters were so flighty. A shame.

    Class::InsideOut and Object::Inside look nice. The former looks svelte and perhaps easier to pick up, while the latter appears to be more comprehensive.
      There is also ovid's Class::BuildMethods which does not care how you implement your objects (but can work with the inside out kind), e.g.
      package Soldier; use strict; use Class::BuildMethods 'name', rank => { default => 'private' }; sub new { my $class = shift; return bless [] => $class; } package main; use warnings; use Data::Dumper; my $foo = Soldier->new; $foo->name('John'); $foo->rank('Major'); printf "name: %s, rank: %s\n", $foo->name, $foo->rank; print Dumper($foo) . "\n";
      output:
      name: John, rank: Major $VAR1 = bless( [], 'Soldier' );
        Ummm, I like that quite a bit. So my new code would look like this:
        package Games::Traveller::Sophont; { use Class::BuildMethods qw/ name longname homeworld star orbit status niche ... etc ... /; sub new { bless {}, shift } ... etc ... } 1; package My::Purple::Blovinator; my $foo = new Games::Traveller::Sophont; $foo->name( "Chamaxi" ); ... etc ...
        Yeah... yeah, I think I like that a lot.