Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You may as well just use a singleton pattern if you're going to do this, and at least that's easier to maintain if your use cases change.


Just use a flat C-style function API instead of a Singleton object. Singletons are only really needed in languages that enforce the 'everything is an object' folly.


Singletons are just globals for people who have learnt "globals are bad" but lack a deeper understanding


Not exactly. For example, you can have a singleton object that maintains a persistent connection to a db to persist logs to. No one's going to inject the "ElasticsearchLogger" object in their method/class by accident, and even then, they'll only have access to the singleton state that the class lets them have access to. So now your private Counter variable is inside a global singleton without being accessible by anyone, even if that person is disregarding all of OP's rules.


Not sure how that is any different besides construction of an object rather than a file with globals?


A singleton object can encapsulate the global state, converting global variables to private fields. How would this be different? Because a counter singleton can for example disallow directly setting the count field, only allowing the count to be incremented through a method.


You don't need objects for that kind of encapsulation, just don't export your variables across module / unit boundaries.


Yes good point. The module/unit acts as the singleton instance, in a sense, though that might be the incorrect way to put it.

In any case, I think variables that are “global” but encapsulated in this way lose the potential for harm we associate with a global variable the whole program may be directly reading and writing.


I think the suggestion is to encapsulate global mutable state behind a strict interface (if you want global mutable state)


I'm the author

No, please don't




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: