"Object Pascal: Immutable State"
"Object Pascal: Immutable State"
New blog article by Marcos Douglas B. Santos around the Pascal/Delphi language for https://tmssoftware.com/site/
https://www.tmssoftware.com/site/blog.asp?post=453
https://www.tmssoftware.com/site/blog.asp?post=453
New blog article by Marcos Douglas B. Santos around the Pascal/Delphi language for https://tmssoftware.com/site/
https://www.tmssoftware.com/site/blog.asp?post=453
https://www.tmssoftware.com/site/blog.asp?post=453
I really don't want to bash this article but I just cannot let this misinformation slip through uncommented.
ReplyDeleteFirst sentence is already wrong:
"In object-orientation, an object can be considerable immutable even if it... changes."
No - immutable means state does not change.
Later the entire talk about secondary attributes and changing those not violating the immutability of the containing object is wrong. It does not matter if the state of the instance itself or any aggregation changes. If any of its aggregations change the containing instance is not immutable anymore.
One of the reasons to use immutable objects is that you can easily use them in multi threading as you know their state cannot be changed. Now if you still can add to some internal list that violates the immutability of its containing instance as certainly any of its API will return different results after the internal list changed (exception would be you are implementing a persistent data structure - see https://en.wikipedia.org/wiki/Persistent_data_structure).
FWIW I find this explanation way more helpful:
https://stackoverflow.com/a/622773/587106
Stefan Glienke in the "External content" consider this code:
ReplyDeletefunction TFile.Stream: IDataStream;
begin
Result := TDataStream.New(FFileName);
end;
"Although the result of the method may be different for each call — the contents of the file can be changed by another process — the object would remain unchanged because its state (FFilePath attribute) has not been changed."
Do you agree this object is immutable, but not constant?
If you don't, stop here because we won't agree at all.
[pause]
So, if I have a FStream as an attribute and I don't change the "pointer of the object in memory", ie, FStream after created is never recreated, what is the difference to read a content from file or memory?
FStream is the same, but only his content (doesn't matter where it comes) changes.
I completely agree with the stackoverflow link. This don't bash the article at all.
What are you referring to with "this object"? TFile or TDataStream?
ReplyDeleteFirst one it not affected because TFile.Stream is a pure function which does not change the state of TFile (which does not say anything about TFile being mutable or not because we don't know all other methods)
We can also not say anything about TDataStream because again we don't know all its methods. If its entire state is only FFileName and not something from the file referred to by using FFileName it is, otherwise its not.
What you are referring to is called non-transitive immutability (not changing the reference itself but the referenced instance is mutable). In many areas where immutability is desired you want transitive immutability. If I pass some TDataStream instance down to some parallel processing code I certainly want it to not fail by either guaranteeing transitive immutability or I need locking primitives to ensure thread-safety.