All, I've been thinking about what it takes to do vtables for hashes a bit and chatting with Yves about it. At face value, this doesn't sound too hard and the potential benefit of having multiple hash-like structure implementations that can be swapped on a per-instance basis seems like a real win, for example, to tighten up the size of objects. To do an early prototype, mangling all the current hash interfacing code to put in a vtable abstraction layer is probably quite doable[1]. Bits that make me really scratch my head are: - Caching of hash values. If we swap the hash implementation, the actual value computed on a key string is at least going to change if not invalidated altogether (eg. in the case of masquerading a tree as a hash). This flies in the case of all places where we cache hash values such as $hash{foo}. Since the container is now polymorphic, caching is out the window. This isn't just a performance issue, but actually makes me wonder how that could even be hacked in at all for an experiment. - The global string table. Clearly, alternate hash implementations would have to opt in to using it in the first place, but they at least need to be able to do so fundamentally. - HE* and friends are part of the API right now, but are really tied to the underlying implementation. I am quite aware that this isn't going to be a complete list of downfalls. So I'd like field some feedback both to hear whether and if so how these could possibly be worked around and which problems I'm missing altogether. --Steffen [1] As a first stab, and for experimentation/compatibility, the current hash API functions could be renamed from hv_foo to hv_foo_internal. Then we create shim functions following the tentative vtable API that invoke them appropriately. Then we create shim functions using the old hv_foo names that follow the old API behaviour and implement those on top of the vtable API. That'd be kind of slow and, depending on the similarity of the current and future APIs, kind of yucky to implement, but it'd most certainly be feasible to experiment with.Thread Next