in reply to Re: Marking an array as already seen ('~'magic virtual table)
in thread Marking an array as already seen

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

  • Comment on Re: Re: Marking an array as already seen ('~'magic virtual table)

Replies are listed 'Best First'.
Re: Re: Re: Marking an array as already seen ('~'magic virtual table)
by shotgunefx (Parson) on Jan 18, 2003 at 10:38 UTC
    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.
    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};
    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."