|
|
|
|
|
by bc_programming
699 days ago
|
|
In this case, By "side effects" I mean non-obvious changes to the static state, Where a seemingly simple function will both rely on static fields to evaluate it's result as well as make changes to various other fields that will subsequently change the result of that function going forward. I don't think one needs a dogmatic adherence to immutability and avoiding side effects to find that to be undesirable. |
|
They mean literally any change at all. If your function is named addOne(&x), then they consider the result of x being one greater to be a “side effect”, whereas I suspect actually sane people such as yourself would not see that as a side effect.
This type of definition fuckery is one reason (among many), that I’ve come to fully disrespect functional programming communities.
One thing that also needs to be understood is that side effects (to your definition) are not explicitly bad things. Side effects ignoring boundaries, ignoring APIs, holding references, etc are probably mostly bad though.
In fact, in gaming, providing hooks to empower side effects is often explicitly good for granting designers mechanic freedom.