in reply to Re^2: Is this proof of concept too evil?
in thread Is this proof of concept too evil?

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

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] };

Replies are listed 'Best First'.
Re^4: Is this proof of concept too evil?
by exodist (Monk) on Jan 18, 2009 at 02:11 UTC
    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

      Both of those are modules that use c/c++ and are not core

      That's a non-issue. Lexical::Alias is trivial to build using cpan and available via ppm for Windows.

        Sorry, it must have sounded like I did not want to use it just because of that.. non-core and c/c++ modules are not a problem, however they would break some parts of what I am working on.