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