Re: Efficient HV fetches without recomputing the key hash

[email protected] ("Paul \"LeoNerd\" Evans") Mon, 18 May 2026 17:50:34 +0100
Newsgroups perl.perl5.porters
Message-ID <[email protected]>
On Fri, 15 May 2026 13:29:45 +0200
"Ruud H.G. van Tol" via perl5-porters <[email protected]> wrote:

> Is this also already covered by Magic-2?

Kindof, yes and no.

"Magic v2" itself - https://github.com/Perl/PPCs/pull/89 - is really
just about making it possible to have more fine-grained types of magic
with different functions in the functions table. There's a suggestion in
there that there can be specific magic function table types for arrays,
hashes, etc...

One important conceptual hurdle though is that even under Magic v2, the
entire concept of magic is simply "event notification". It's a set of
void-returning trigger functions that tell you an event has happened
(or is about to happen). This makes a lot of things simple as any given
SV can have multiple magics attached and it doesn't really matter even
what order they're in or how many of those functions are really
implemented. You don't get to decide how an event happens; you're just
informed that it did.

If we were to use Magic v2 for "user-defined hashes", or arrays, or
whatever, that then puts us into a new kind of magic that has to
actually answer questions - e.g. "get me the element at this
key/index". Suddenly now there needs to be *exactly one* magic v2 table
on a given SV that provides that full set of API requirements to be an
array, hash, whatever. There are now has concerns about what happens if
we try to attach multiple such magics, or if a given magic table
doesn't provide all the answers, etc. They're all questions that can
potentially just be solved by `croak("Can't attach this magic table")`
as part of the sv_magicv2_add() call, but it's still something that
needs to be thought about.

-- 
Paul "LeoNerd" Evans

[email protected]
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS