Skip to content

Conversation

@Stuart-Mouse
Copy link

Currently only supporting string as the key type.

@rexim
Copy link
Member

rexim commented Jan 29, 2026

Linking back to upstream rluba#35
This also potentially supersedes #1

@Stuart-Mouse I think I roughly understand the gist of the trick you are pulling off here. It's pretty cool actually! I have only one question though. If the implementation of the original Hash_Table changes, does it break the Any_Hash_Table? And if so how easily is it detectable at compile time? If Jon changes Hash_Table one day would we get some easy to follow compilation errors and fix things up?

Also,

Currently only supporting string as the key type.

I don't think any other key type needs any support. Afaik, JSON objects only support string keys anyway. :D

@Stuart-Mouse
Copy link
Author

@rexim Unfortunately yeah, I think certain changes to the hash table would cause the Any_Hash_Table to break. I'm not sure how avoidable that is though, since there's no way around the fact that in order to do this in a runtime-generic way you have to entirely reimplement the basic procedures. I could add some more asserts to help prevent basic things like if the struct parameters get reordered or if the internal layout changes at all, but if the actual logic changes for how hashing occurs, then things could just silently break. (From the maintainer's side this is probably not too much of an issue since any changes to Hash Table should be reflected in the changelog for the language, but of course its not ideal if users of Jaison just get an inexplicable break one day because they didn't pull the latest version.)

This is sort of the reason I think it may be better to offer a generalized intercept so that users can poke in their own special handling for things like the Hash_Table. I think if users are knowingly taking the extra dependency then at least they'll be aware that it's a potential point of failure. I have some similar functionality in my own parser that I could try replicating here. If you think that's a better idea I can throw together a little proposal in a different PR and we put a pin in the Hash Table thing until then.

@rexim
Copy link
Member

rexim commented Jan 29, 2026

its not ideal if users of Jaison just get an inexplicable break one day because they didn't pull the latest version

Yeah, I feel like subtle undetected changes may send the users down a very annoying rabbit hole...

My idea was to make Jaison operate on Table(string, [N]u8) where N is determined at compile time from the type infos that should also be available at compile time. So basically make Jaison parsers polymorph at different sizes of types. I feel like this would be an ideal solution. I'll try to implement it when I get some spare time. Thank you for submitting this PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants