in reply to Is this proof of concept too evil?

First of all, I find tsvars rather clunky. Two args per var would be much better. 

tsvars(
   a => my $a = 'A',
   b => my $b = 'B',
);

tsvars(
   a => my $a2,
   b => my $b2 = 'B2',
);

[download]
my ($ident, $value) = @_[0,1];
tie( $_[1], 'MyTest::Scalar', $ident );
$_[1] = $value if defined($value);
splice(@_, 0, 2);

[download]

But you're just emulating aliases using tie magic. Magic adds a lot of overhead. You'd probably be better using true aliases. The interface is much more flexible too. 

use Data::Alias qw( alias );

my ($ident, $value) = @_[0,1];
alias $_[1] = $VALUES{ $ident );
$_[1] = $value if defined($value);
splice(@_, 0, 2);

[download]

Replies are listed 'Best First'.
Re^2: Is this proof of concept too evil?
by exodist (Monk) on Jan 18, 2009 at 01:01 UTC
    Yay! I learned something new, never used alias before, thanks a bunch!
[reply]
      Note: Data::Alias doesn't compile on Windows since it accesses private Perl internals (which the Window build process forbids) to make its powerful syntax possible. I just found Lexical::Alias which doesn't have that problem. 
      use Lexical::Alias qw( alias );

my ($ident, $value) = @_[0,1];
alias $_[1], $VALUES{ $ident );
$_[1] = $value if defined($value);
splice(@_, 0, 2);

      [download]

      Update: It looks like Lexical::Alias can't alias a scalar to a hash element. It looks like you'll need to use tie as a fallback after all. Here's a slightly simpler version than what you had: 

      {
    package My::Tie::Scalar::Alias;

    use strict;
    use warnings;

    use Tie::Scalar qw( );

    our @ISA = 'Tie::Scalar';

    sub TIESCALAR {
        my ($class, $ref) = @_;
        return bless $ref, $class;
    }

    sub FETCH { my $self = shift; return $$self;  }
    sub STORE { my $self = shift; $$self = shift; }
}


tie $_[1], 'My::Tie::Scalar::Alias', \$VALUES{ $_[0] };

      [download]
[reply]
[d/l]
[select]
        I think I will stick with tie for now:
        • Performance is not an issue in this case
        • Both of those are modules that use c/c++ and are not core
        • I am keeping my deps at a minimum when possible because my module will bundle itself for other systems, the less I have to bundle the better, currently it is YAML::Syck and Getopt::Long only.
        • This is a proof of concept, the class I am tying to in production does more
[reply]

In Section Meditations