Return to Answer

Here's some immutable data that is constantly moving around.

Ryu always did know how to follow through. As you can see here, just because the data is immutable doesn't mean nothing at all changes.

Specifically, it seems like with an immutable solution, you would run out of memory fast by constantly appending to the immutable data structure. Seems like you would have to limit the amount of history/versioning on the data structure, which means only limited immutability.

That's a resource concern which for the most part can be abstracted away. You can record every request to change state immutably and make state into something you calculate by replaying all of those state change requests. If doing that compactly isn't enough you can always record state at certain points and push previous requests off to long term storage. How often is a tuning variable. Oh and you can record those states, immutably.

Second, it seems like the overhead of creating these new objects would be too much, though perhaps there is a low-level data structure with pointers or something that you could use that would make this negligible.

This is fine as long as your constructors don't do silly things. Stick to validating and setting class attributes. That way the cost of creating new objects will be no more then that with a little pointer addition thrown in. Never optimize based on what something "seems like". Test and be sure.

Here's some immutable data that is constantly moving around.

Ryu always did know how to follow through. As you can see here, just because the data is immutable doesn't mean nothing at all changes.

Specifically, it seems like with an immutable solution, you would run out of memory fast by constantly appending to the immutable data structure. Seems like you would have to limit the amount of history/versioning on the data structure, which means only limited immutability.

That's a resource concern which for the most part can be abstracted away. You can record every request to change state immutably and make state into something you calculate by replaying all of those state change requests. If doing that compactly isn't enough you can always record state at certain points and push previous requests off to long term storage. How often is a tuning variable. Oh and you can record those states, immutably.

Second, it seems like the overhead of creating these new objects would be too much, though perhaps there is a low-level data structure with pointers or something that you could use that would make this negligible.

This is fine as long as your constructors don't do silly things. Stick to validating and setting attributes. That way the cost of creating new objects will be no more then that with a little pointer addition thrown in. Never optimize based on what something "seems like". Test and be sure.

Here's some immutable data that is constantly moving around.

Ryu always did know how to follow through. As you can see here, just because the data is immutable doesn't mean nothing at all changes.

Specifically, it seems like with an immutable solution, you would run out of memory fast by constantly appending to the immutable data structure. Seems like you would have to limit the amount of history/versioning on the data structure, which means only limited immutability.

That's a resource concern which for the most part can be abstracted away. You can record every request to change state immutably and make state into something you calculate by replaying all of those state change requests. If doing that compactly isn't enough you can always record state at certain points and push previous requests off to long term storage. How often is a tuning variable. Oh and you can record those states, immutably.

Second, it seems like the overhead of creating these new objects would be too much, though perhaps there is a low-level data structure with pointers or something that you could use that would make this negligible.

This is fine as long as your constructors don't do silly things. Stick to validating and setting class attributes and the cost of creating new objects will be no more then that with a little pointer addition thrown in. Never optimize based on what something "seems like". Test and be sure.

Here's some immutable data that is constantly moving around.

Ryu always did know how to follow through. As you can see here, just because the data is immutable doesn't mean nothing at all changes.

Specifically, it seems like with an immutable solution, you would run out of memory fast by constantly appending to the immutable data structure. Seems like you would have to limit the amount of history/versioning on the data structure, which means only limited immutability.

That's a resource concern which for the most part can be abstracted away. You can record every request to change state immutably and make state into something you calculate by replaying all of those state change requests. If doing that compactly isn't enough you can always record state at certain points and push previous requests off to long term storage. How often is a tuning variable. Oh and you can record those states, immutably.

Second, it seems like the overhead of creating these new objects would be too much, though perhaps there is a low-level data structure with pointers or something that you could use that would make this negligible.

This is fine as long as your constructors don't do silly things. Stick to validating and setting class attributes. That way the cost of creating new objects will be no more then that with a little pointer addition thrown in. Never optimize based on what something "seems like". Test and be sure.

Here's some immutable data that is constantly moving around.

Ryu always did know how to follow through. As you can see here, just because the data is immutable doesn't mean nothing at all changes.

Specifically, it seems like with an immutable solution, you would run out of memory fast by constantly appending to the immutable data structure. Seems like you would have to limit the amount of history/versioning on the data structure, which means only limited immutability.

That's a resource concern which for the most part can be abstracted away. You can record every request to change state immutably and make state into something you calculate by replaying all of those state change requests. If doing that compactly isn't enough you can always record state at certain points and push previous requests off to long term storage. How often is a tuning variable.

Second, it seems like the overhead of creating these new objects would be too much, though perhaps there is a low-level data structure with pointers or something that you could use that would make this negligible.

This is fine as long as your constructors don't do silly things. Stick to validating and setting class attributes and the cost of creating new objects will be no more then that with a little pointer addition thrown in. Never optimize based on what something "seems like". Test and be sure.

Here's some immutable data that is constantly moving around.

Ryu always did know how to follow through. As you can see here, just because the data is immutable doesn't mean nothing at all changes.

Specifically, it seems like with an immutable solution, you would run out of memory fast by constantly appending to the immutable data structure. Seems like you would have to limit the amount of history/versioning on the data structure, which means only limited immutability.

That's a resource concern which for the most part can be abstracted away. You can record every request to change state immutably and make state into something you calculate by replaying all of those state change requests. If doing that compactly isn't enough you can always record state at certain points and push previous requests off to long term storage. How often is a tuning variable. Oh and you can record those states, immutably.

Second, it seems like the overhead of creating these new objects would be too much, though perhaps there is a low-level data structure with pointers or something that you could use that would make this negligible.

This is fine as long as your constructors don't do silly things. Stick to validating and setting class attributes and the cost of creating new objects will be no more then that with a little pointer addition thrown in. Never optimize based on what something "seems like". Test and be sure.