4

I have a hash with a few values that are not scalar data but rather anonymous subroutines that return scalar data. I want to make this completely transparent to the part of the code that looks up values in the hash, so that it doesn't have to be aware that some of the hash values may be anonymous subroutines that return scalar data rather than just plain old scalar data.

To that effect, is there any way to have the anonymous subroutines executed when their keys are accessed, without using any special syntax? Here's a simplified example that illustrates the goal and the problem:

#!/usr/bin/perl

my %hash = (
    key1 => "value1",
    key2 => sub {
        return "value2"; # In the real code, this value can differ
    },
);

foreach my $key (sort keys %hash) {
    print $hash{$key} . "\n";
}

The output I would like is:

perl ./test.pl
value1
value2

Instead, this is what I get:

perl ./test.pl
value1
CODE(0x7fb30282cfe0)

7 Answers 7

5

As noted by Oleg, it's possible to do this using various more or less arcane tricks like tie, overloading or magic variables. However, this would be both needlessly complicated and pointlessly obfuscated. As cool as such tricks are, using them in real code would be a mistake at least 99% of the time.

In practice, the simplest and cleanest solution is probably to write a helper subroutine that takes a scalar and, if it's a code reference, executes it and returns the result:

sub evaluate {
    my $val = shift;
    return $val->() if ref($val) eq 'CODE';
    return $val;  # otherwise
}

and use it like this:

foreach my $key (sort keys %hash) {
    print evaluate($hash{$key}) . "\n";
}
Sign up to request clarification or add additional context in comments.

6 Comments

I would suggest doing something similar via an object might also work, and not be as evil as tieing.
"and not be as evil as tieing" What is this antipathy towards tying? "doing something similar via an object" will result in a lot more code. The only thing I have against tie is that the code is a lot slower than ordinary Perl access to a variable, as it is written in Perl instead of C. For anything but huge data structures that's fine
"needlessly complicated and pointlessly obfuscated" See my solution. An extra fifteen lines of code? In a separate module file? And half of that is for some cute initialisation syntax in the calling code. "As cool as such tricks are, using them in real code would be a mistake at least 99% of the time" I think this is a needlessly disparaging and scaremongering answer. You are clearly unfamiliar with tie
I dislike the 'action at a distance' element of tie - much like overloading, if done well it's useful, and if done badly is a road to really horrible code.
@Sobrique: Fine, but citing "action at a distance" is much more useful than assigning a label of "evil"
|
4

I don't believe that the words that others have written in disapproval of the tie mechanism are warranted. None of the authors seem to properly understand how it works and what core library backup is available

Here's a tie example based on Tie::StdHash

If you tie a hash to the Tie::StdHash class then it works exactly as a normal hash. That means there's nothing left to write except for methods that you may want to override

In this case I've overridden TIEHASH so that I could specify the initialisation list in the same statement as the tie command, and FETCH, which calls the superclass's FETCH and then makes a call to it if it happens to be a subroutine reference

Your tied hash will work as normal except for the change that you have asked for. I hope it is obvious that there is no longer a direct way to retrieve a subroutine reference if you have stored it as a hash value. Such a value will always be replaced by the result of calling it without any parameters

SpecialHash.pm

package SpecialHash;

use Tie::Hash;
use base 'Tie::StdHash';

sub TIEHASH {
    my $class = shift;
    bless { @_ }, $class;
}

sub FETCH {
    my $self = shift;
    my $val = $self->SUPER::FETCH(@_);
    ref $val eq 'CODE' ? $val->() : $val;
}

1;

main.pl

use strict;
use warnings 'all';

use SpecialHash;

tie my %hash, SpecialHash => (
    key1 => "value1",
    key2 => sub {
        return "value2"; # In the real code, this value can differ
    },
);

print "$hash{$_}\n" for sort keys %hash;

output

value1
value2



Update

It sounds like your real situation is with an existing hash that looks something like this

my %hash = (
    a => {
        key_a1 => 'value_a1',
        key_a2 => sub { 'value_a2' },
    },
    b => {
        key_b1 => sub { 'value_b1' },
        key_b2 => 'value_b2',
    },
);

Using tie on already-populated variables isn't so neat as tying then at the point of declaration and then inserting the values as the data must be copied to the tied object. However the way I have written the TIEHASH method in the SpecialHash class makes this simple to do in the tie statement

If possible, it would be much better to tie each hash before you put data into it and add it to the primary hash

This program ties every value of %hash that happens to be a hash reference. The core of this is the statement

tie %$val, SpecialHash => ( %$val )

which functions identically to

tie my %hash, SpecialHash => ( ... )

in the previous code but dereferences $val to make the syntax valid, and also uses the current contents of the hash as the initialisation data for the tied hash. That is how the data gets copied

After that there is just a couple of nested loops that dump the whole of %hash to verify that the ties are working

use strict;
use warnings 'all';
use SpecialHash;

my %hash = (
    a => {
        key_a1 => 'value_a1',
        key_a2 => sub { 'value_a2' },
    },
    b => {
        key_b1 => sub { 'value_b1' },
        key_b2 => 'value_b2',
    },
);

# Tie all the secondary hashes that are hash references
#
for my $val ( values %hash ) {
    tie %$val, SpecialHash => ( %$val ) if ref $val eq 'HASH';
}

# Dump all the elements of the second-level hashes
#
for my $k ( sort keys %hash ) {

    my $v = $hash{$k};
    next unless ref $v eq 'HASH';

    print "$k =>\n";

    for my $kk ( sort keys %$v ) {
        my $vv = $v->{$kk};
        print "    $kk => $v->{$kk}\n" 
    }
}

output

a =>
    key_a1 => value_a1
    key_a2 => value_a2
b =>
    key_b1 => value_b1
    key_b2 => value_b2

7 Comments

This is basically exactly what I was looking for!
Okay… next question. How do I do this when it's not actually a hash, but a hashref that I initialize?
@iLikeDirt, No change. Just tie the referenced hash as before.
Basically, is there any way to initialize an anonymous SpecialHash ref? In production, what I have is a two-dimensional data structure that's an anonymous hashref of anonymous hashrefs, and I'd like them all to be SpecialHashes.
@iLikeDirt, You could tie each second-level hash using tie %$_, SpecialHash::, %$_ for values(%$HoH);. More flexible solutions are far more complicated.
|
2

There's a feature called "magic" that allows code to be called when variables are accessed.

Adding magic to a variable greatly slows down access to that variable, but some are more expensive than others.

  • There's no need to make access to every element of the hash magical, just some values.
  • tie is an more expensive form of magic, and it's not needed here.

As such, the most efficient solution is the following:

use Time::HiRes     qw( time );
use Variable::Magic qw( cast wizard );

{
   my $wiz = wizard(
      data => sub { my $code = $_[1]; $code },
      get => sub { ${ $_[0] } = $_[1]->(); },
   );

   sub make_evaluator { cast($_[0], $wiz, $_[1]) }
}

my %hash;
$hash{key1} = 'value1';
make_evaluator($hash{key2}, sub { 'value2@'.time });

print("$hash{$_}\n") for qw( key1 key2 key2 );

Output:

value1
[email protected]
[email protected]

Other examples:

my %hash; make_evaluator($hash{key}, sub { ... });
my $hash; make_evaluator($hash->{$key}, sub { ... });

my $x; make_evaluator($x, sub { ... });
make_evaluator(my $x, sub { ... });

make_evaluator(..., sub { ... });
make_evaluator(..., \&some_sub);

You can also "fix up" an existing hash. In your hash-of-hashes scenario,

my $hoh = {
   { 
      key1 => 'value1',
      key2 => sub { ... },
      ...
   },
   ...
);

for my $h (values(%$hoh)) {
   for my $v (values(%$h)) {
      if (ref($v) eq 'CODE') {
         make_evaluator($v, $v);
      }
   }
}

3 Comments

Ah, this actually looks perfect, assuming I can figure out how to implement it…
Updated answer to show how to "fix up" your hash-of-hashes.
This is what I ended up doing and it worked magnificently. Thanks very much!
2

Yes you can. You can either tie hash to implementation that will resolve coderefs to their return values or you can use blessed scalars as values with overloaded mehods for stringification, numification and whatever else context you want to resolve automatically.

1 Comment

Variable::Magic would also work, in a similar fashion to tie, with more complication but also more speed.
2

One of perl's special features for just such a use case is tie. This allows you to attach object oriented style methods, to a scalar or hash.

It should be used with caution, because it can mean that your code is doing really strange things, in unexpected ways.

But as an example:

#!/usr/bin/env perl

package RandomScalar;

my $random_range = 10;

sub TIESCALAR {
    my ( $class, $range ) = @_;
    my $value = 0;
    bless \$value, $class;
}

sub FETCH {
    my ($self) = @_;
    return rand($random_range);
}

sub STORE {
    my ( $self, $range ) = @_;
    $random_range = $range;
}

package main;

use strict;
use warnings;

tie my $random_var, 'RandomScalar', 5;

for ( 1 .. 10 ) {
    print $random_var, "\n";
}

$random_var = 100;
for ( 1 .. 10 ) {
    print $random_var, "\n";
}

As you can see - this lets you take an 'ordinary' scalar, and do fruity things with it. You can use a very similar mechanism with a hash - an example might be to do database lookups.

However, you also need to be quite cautious - because you're creating action at a distance by doing so. Future maintenance programmers might well not expect your $random_var to actually change each time you run it, and a value assignment to not actually 'set'.

It can be really useful for e.g. testing though, which is why I give an example.

In your example - you could potentially 'tie' the hash:

#!/usr/bin/env perl

package MagicHash;

sub TIEHASH {
    my ($class) = @_;
    my $self = {};
    return bless $self, $class;
}

sub FETCH {
    my ( $self, $key ) = @_;
    if ( ref( $self->{$key} ) eq 'CODE' ) {
        return $self->{$key}->();
    }
    else {
        return $self->{$key};
    }
}

sub STORE {
    my ( $self, $key, $value ) = @_;
    $self->{$key} = $value;
}

sub CLEAR {
    my ($self) = @_;
    $self = {};
}

sub FIRSTKEY {
    my ($self) = @_;
    my $null = keys %$self;    #reset iterator
    return each %$self;
}

sub NEXTKEY {
    my ($self) = @_;
    return each %$self;
}

package main;

use strict;
use warnings;
use Data::Dumper;

tie my %magic_hash, 'MagicHash';
%magic_hash = (
    key1 => 2,
    key2 => sub { return "beefcake" },
);

$magic_hash{random} = sub { return rand 10 };

foreach my $key ( keys %magic_hash ) {
    print "$key => $magic_hash{$key}\n";
}
foreach my $key ( keys %magic_hash ) {
    print "$key => $magic_hash{$key}\n";
}
foreach my $key ( keys %magic_hash ) {
    print "$key => $magic_hash{$key}\n";
}

This is slightly less evil, because future maintenance programmers can use your 'hash' normally. But dynamic eval can shoot the unwary in the foot, so still - caution is advised.

And alternative is to do it 'proper' object oriented - create a 'storage object' that's ... basically like the above - only it creates an object, rather than using tie. This should be much clearer for long term usage, because you won't get unexpected behaviour. (It's an object doing magic, which is normal, not a hash that 'works funny').

1 Comment

Take a look at Tie::Hash and similar modules. There's a lot of library support, and generally no need to rewrite all of the access methods unless you want to change them. Take a look at my own solution
1

You need to identify when a code ref is present, then execute it as an actual call:

foreach my $key (sort keys %hash) {
    if (ref $hash{$key} eq 'CODE'){
        print $hash{$key}->() . "\n";
    }
    else {
        print "$hash{$key}\n";
    }
}

Note that you may consider making all of the hash values subs (a true dispatch table) instead of having some that return non-coderefs and some that return refs.

However, if you define the hash as such, you don't have to do any special trickery when it comes time to use the hash. It calls the sub and returns the value directly when the key is looked up.

key2 => sub {
    return "value2";
}->(),

1 Comment

"It calls the sub and returns the value directly when the key is looked up." Maybe this is what you meant, but the sub is only called once, when the hash is initialized. This probably won't work if the OP's subs have side effects (but is obviously much more efficient if there aren't side effects).
0

No, not without some ancillary code. You are asking for a simple scalar value and a code reference to behave in the same way. The code that would do that is far from simple and also injects complexity between your hash and its use. You might find the following approach simpler and cleaner.

You can make all values code references, making the hash a dispatch table, for uniform invocation

my %hash = (
    key1 => sub { return "value1" },
    key2 => sub {
        # carry on some processing ...
        return "value2"; # In the real code, this value can differ
    },
);

print $hash{$_}->() . "\n" for sort keys %hash;

But of course there is a minimal overhead to this approach.

9 Comments

Not strictly true. There are ways it can be done. Whether they are a good idea is a different matter...
@Sobrique Yes, thank you for the comment. I meant to guard against that by "No, not like this" ... but that was not good enough at all. I thought that OP was about something direct and simple, not injecting layers of code and complexity between his hash and its use. (Also, I don't know exactly how to do that -- and will read your and Borodin's answer with pleasure!) Given where this question went I'll probably remove this post.
May I suggest you rephrase to "It's possible, but it requires complicated and obscure code. You might find it simpler and cleaner to use the following approach..."
@ikegami Thank you for the comment. I wasn't sure whether this post had a place on this page, given the other answers. But I suppose it is one simple way.
@zdim: Hey it's your question. You can do whatever you like with it! I made the edit in an attempt to help you out with phrasing "not like this" more clearly. You're always free to roll back any changes that others have made to your post, and you certainly don't need to check with anyone else before you make changes
|

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.