Tie::RefHash comes with perl.

I don't think I'd use Memoize.

Untested:

use Tie::RefHash; 
{
    tie my %refhash, 'Tie::RefHash'; 
    sub canonicalize_array { 
        my $ref = shift; 
        return $ref if exists $refhash{$ref};
 
        # Otherwise canonicalize the array.

        $refhash{$ref}++;  
        $ref;
    } 
}
[download]

Edit: Added the obvious $refhash{$ref}++; line.

-sauoq
"My two cents aren't worth a dime.";

sub foy {
  my $ref = shift;

  canonicalize($ref) unless $ref->isa('_Canonical');
}
[download]

If I store a flag in a hash indexed by the ref's string, is that string always the same?

Yes. A reference to the same structure will always stringify the same (in the same instance of the program of course), otherwise, the perl garbage collector couldn't work (reference counting is, well, reference counting, so it has to stringify the same).

Also, to learn about attributes, check out the pragma.

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! ** The Third rule of perl club is a statement of fact: pod is sexy.

Yes. A reference to the same structure will always stringify the same (in the same instance of the program of course), otherwise, the perl garbage collector couldn't work (reference counting is, well, reference counting, so it has to stringify the same).

Unless, of course, it's a reference to a class that has overloaded ""... in which case you'll have to use refaddr from Scalar::Util :-)

Yes, "$ref" is always the same if $ref= \@array; for the same array. Just go ahead and use it as the key in a hash. This is how Tie::RefHash is able to work.

You can even use $hash{0+$ref} which is probably faster.

OK, why is {0+$ref} faster? I can see the different semantics... $hash{$ref} converts the ref to a string, while $hash{0+$ref} converts the ref to a number and then to a string. A quick test shows that converting a ref to a number returns (no surprise) a number, probably the machine address of an underlying unique piece of data in the interpreter, the same as the hex value shown in the stringification form.

So why would the latter be faster?

—John

Just a tiny bit faster, but really "simpler" might have been a better description. It won't get confused if someone (re)blesses the array, for example. It will (probably, as I said) be slightly faster because it doesn't even have to look up blessedness and put that into the string and it will use a shorter string. *shrug*

It was a quick note I added at the end. I prefer 0+$ref over "$ref" in general. But the speed isn't really the point. Just not doing extra work that might get in the way.

                - tye

use Magic::Attach;
sub bind {
 my ($ref,$shadow) = @_;
 attach($ref,$shadow, 'optional namespace');
}
# Later
sub foo {
  my $ref = shift;
  my $shadow = attach($ref);
  $shadow =  attach($ref,{}) unless $shadow;
  my $count = $shadow->{Someattribute};
}
[download]

Interesting. You're saying that in the perl implementation, there is a user-defined "slot" that can hold ... what? A ref to another thing, which you choose to be a hash for your property table, it seems. But you called it a user-defined v-table, like it's a table rather than a single slot. Or maybe that's just the inteded use?

Care to tell us more about that? Describing it might help gell your knowledge about XS guts.

—John

There are different types of magic (this is how tie is implemented amongst other things.), I am using the '~' user extension type. Multiple variables can be attached to a reference as well and as long as they specify a different 'namespace', they won't clobber each other.

I choose to let my implementation use any ref blessed or not. The table portion refers to additional methods that can be implemented.

    Function pointer    Action taken
    ----------------    ------------
    svt_get             Do something after the value of the SV is retr
+ieved.
    svt_set             Do something after the SV is assigned a value.
    svt_len             Report on the SV's length.
    svt_clear           Clear something the SV represents.
    svt_free            Free any extra storage associated with the SV.
[download]

To get the value bound to the variable, I'm simply returning it's pointer stored in mg_ptr. See the Magic Virtual Tables section in perldoc:perlguts for a better explanation (It's late and I'm bug-eyed tired). I'm only implementing free though it could be extended to open up the other functions. I probably will do that. If I did, let's say you were trying to make a cache of the output of some larger process, you would be able to add a callback to the data structure via set && clear magic that would invalidate that part of the cache when updated and it wouldn't require any direct action by the user.

The implementation as it stands is exposed through a single routine but this might change as the function attach is almost too DWIM.
Here's a run down of what it looks like.

 attach ( $somepointer, { seen=>1 }, 'opt_name_to_avoid_collision') or
+ die "Couldn't attach;
 # Later on...
 my $attached = attach($somepointer);
 $attached->{bar}= uc $attached->{bar};
[download]

Not a compelling example above but I can think of some better ones which I'll post when it's cleaned up. If you think about how matching works and how it tracks where it is in a string, well you can do the same thing with any sub now without trying to compute unique keys from caller() + data and storing it in a hash. Lazily processing lists non-destructively is another good example.

-Lee

"To be civilized is to deny one's nature."

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.