Why uvar magic must die
Uvar magic must die. Maybe it’s too late for a complete removal, but it’s use should at least be discouraged. One of the reasons is that it’s actually two very different things that don’t have all that much in common.
Scalar uvar magic
Scalar uvar magic isn’t actually evil, it’s just fairly useless. It’s a way to add get and set hooks to scalars. It may have been a useful interface back when it was introduced in 1993, but with the introduction of custom magic vtables in 5.8 it stopped particularly useful. The new interface is more powerful in many ways and in typical cases it that takes less code to use. There’s absolutely no reason why anyone should still be using scalar uvar magic unless you have to maintain compatibility with 5.6.
Hash uvar magic
I blogged before about what hash uvar magic is and how to use it. Hash uvar magic is an abomination. It is the single most horrible interface in the whole of the perl API and that is an achievement. p5p must have been asleep when they allowed it in.
You may wonder, why is it so evil? It abuses the relatively sane interfaces of scalar uvar magic and uses for some completely different purposes. Parameters and even properties of the parameters get completely new functions. It’s a case of fitting a square peg in a round hole.
The callback doesn’t even receive it’s most important parameter (the key value) as an argument! You have to use mg_find
to extract it out of one of the arguments (the hash). Equally bad, there’s absolutely no way to add data to the magic (other than adding more magic) because all possible fields are already in use: uvar itself uses mg_ptr
and mg_len
. The hash magic clobbers both mg_obj
and uf_index
.
The saddest thing is that all of this wasn’t necessary. It should have been easy to define some new kind of magic that passes it’s data in a more sane way quite easily. Maybe it’s not too late yet and the current API can be deprecated in favor of something sane (it’s not like people are using it a lot so far).
Leave a comment