Skip to main content

Timeline for Why is Global State so Evil?

Current License: CC BY-SA 3.0

19 events
when toggle format what by license comment
Oct 14, 2020 at 22:09 comment added CpILL I find that mutable global state is OK if you put strict controls on it i.e. only one process is allowed to write to it and the rest can only read (assuming that you can guarantee this contract in a multi-developer environment)
Dec 27, 2018 at 21:06 comment added Yug Singh @mikera could you give some read programming examples illustrating the tricky bugs from mutable global state? What I can think of is a simple one : consider a program for sending emails to users. Now users are getting stored in a static list.Now since static variables are loaded once when class is loaded and they persist throughout app life therefore for the first time say the program sent mail to u1 and u2. Next time if we want to send mails to u3 and u4 then being static list the mail will be sent to u1 and u2 again and this goes on.Pls let me know if my example is reasonable enough.
Dec 21, 2016 at 11:15 history wiki removed yannis
Sep 13, 2014 at 10:04 comment added maaartinus Yes, that's what I did. And there's a variable declared as State state and that's why I call the class "State", too. A purely functional approach... I haven't really thought of it, sounds interesting.
Sep 13, 2014 at 8:24 comment added Giorgio @maaartinus: IMO you have just moved the mutation from the object (mutable object == object with mutable member variables) to the mutable variable that can point to different immutable snapshots (immutable objects). The state of your system is now represented by that variable. In a purely functional approach you would have a stream of immutable objects: both the objects and the stream are immutable.
Sep 13, 2014 at 3:53 comment added maaartinus @Giorgio Once I started a question here by "State: This is an immutable class...". This obviously means "a snapshot of the state" and the state variable changes by pointing to different instances. But isn't this obvious? When we say "the current state" we also mean a fixed thing, right?
Mar 22, 2014 at 14:47 comment added MarkJ @giorgio The question makes it clear that the variables in question get their values at startup and never change afterwards during program execution (system folders, database credentials). I.e. immutable, it does not change once it has been given a value. Personally I also use the word "state" because it can be different from one execution to another, or on a different machine. There may be better words.
Mar 22, 2014 at 13:14 comment added Giorgio @mikera: Very good answer (+1), but are you sure that "immutable state" is a good formulation? State represents something that can change over time. In my understanding, something that is immutable is not state.
Mar 22, 2014 at 13:12 comment added Giorgio @MarkJ: I cannot find the word immutable in the question, and there is no such thing as "immutable state": as soon as something is immutable, it is a constant and does not model any state. Maybe you meant global constants?
Mar 7, 2014 at 19:30 comment added Jess +1 for mutable/immutable. Immutable globals are ok. Even ones that are lazy loaded but never change. Of course, don't expose global variables, but a global interface or API.
May 17, 2012 at 19:21 history made wiki Post Made Community Wiki by Mike Samuel
May 12, 2012 at 2:06 comment added mikera @Alfredo - very true. Though it's not as bad since at least the scope can be somewhat controlled. But in general, it's easier to just solve the problem by making contexts and dependencies immutable.
May 11, 2012 at 19:26 comment added MarkJ All good stuff, and amen! But the question is about immutable global state
May 11, 2012 at 16:34 comment added Alfredo Osorio I think that passing a context object either by function parameter or dependency injection would cause problems if the context is mutable, same problem as using mutable global state.
May 11, 2012 at 1:59 history edited mikera CC BY-SA 3.0
added 137 characters in body
May 11, 2012 at 1:53 history edited mikera CC BY-SA 3.0
added 137 characters in body
May 11, 2012 at 1:37 history edited mikera CC BY-SA 3.0
added 150 characters in body
May 11, 2012 at 1:32 history edited mikera CC BY-SA 3.0
added 150 characters in body
May 11, 2012 at 1:18 history answered mikera CC BY-SA 3.0