-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
String mutability #29
Comments
Still mulling on this. I want Huo to be fast, but I'm not actually sure what the main contributors to speed are. It would be nice if we had some performance metrics and tests. I will do some research on that. |
My initial thought on the matter would be to make strings immutable, and then later on go back and change things up if necessary. |
Yeah, I like immutability in general, and if it makes the API for strings simpler that's definitely good. If you're inclined to make strings internally immutable I'm fine with making that jump. I haven't got any profiling up yet, but I haven't written any complex programs to push the interpreter either. I'm starting a graph data structure program to test that. |
My guess? Currently it's hideous. There's an awful lot of "just copy all the things" happening at the moment. But profiling will help with that. Actually, my inclination would be to make everything but arrays immutable internally. I'll drop a pull request that does so, and we can see if it makes sense. |
Should strings be mutable internally and/or externally?
As-is, strings are mutable internally, but they appear to be immutable externally.
If we kept to the invariant that strings are immutable internally, it makes some things easier but others harder. Notably: most defensive copies of strings would be removed, but setting characters in strings would be a lot slower (O(n) instead of O(1)), as would concats of a short string to a long string. (Suddenly you have to copy the entire long string)
The text was updated successfully, but these errors were encountered: