What is the correct solution to the FastString code block? Private fields and using a setter to modify it rather than direct access?
Would also be curious about situations where you have to break this condition (e.g. need another data structure with different read performance, or a denormalized database) - how do you mitigate it?
Thanks, I added the specific fix inline in the post.
Unfortunately even with private fields, the programmer still has to write the getter/setter correctly. SPOTty data makes it fast to write the getter/setter because it's unlikely there are bugs.
Non-SPOTty data makes it slow to write the getter/setter because it's so easy to write a bug.
If you have to break it and the data is persisted to disk, then you can write validators which monitor the data to ensure it matches. If it's not persisted to disk, you might be able to still monitor the data within the program, but it's not likely.
What is the correct solution to the FastString code block? Private fields and using a setter to modify it rather than direct access?
Would also be curious about situations where you have to break this condition (e.g. need another data structure with different read performance, or a denormalized database) - how do you mitigate it?
Thanks, I added the specific fix inline in the post.
Unfortunately even with private fields, the programmer still has to write the getter/setter correctly. SPOTty data makes it fast to write the getter/setter because it's unlikely there are bugs.
Non-SPOTty data makes it slow to write the getter/setter because it's so easy to write a bug.
If you have to break it and the data is persisted to disk, then you can write validators which monitor the data to ensure it matches. If it's not persisted to disk, you might be able to still monitor the data within the program, but it's not likely.