4 ms·

A database is only global and mutable if any part of your code can create it. If you isolate the database access to one module and then force other modules to i

by inglor 9y ago

A database is only global and mutable if any part of your code can create it. If you isolate the database access to one module and then force other modules to interact with it through instances of that module in a controlled way - it's not global (but certainly mutable). The same goes to your filesystem, the key thing is: global as global access vs. global as "there is one of it". The same goes for the singleton pattern (which are terrible) vs. just having one of something.

adrianratnapala 9y ago
I don't get this. Once you mutate the database, then the behaviour of any code anywhere that uses the DB, whether directly or through a module is potentially affected by the mutation. Modularisation is great and all, but it doesn't make concurrency and cache-coherency problems go away. In fact it sometimes makes those things worse (or at least more opaque).
- wiz21c 9y ago
  The database (at least the relational ones (I don't know the nosql thing)) is actually a very well behaved global state. It gives you guarantees about its mutability which you often don't have in your own code (well, in mine at least :-)). Moreover, the transactional nature of those DB actually percolates in many places in the code and makes it more reliable. So I'd say the database is a very special mutable thing, it's not as general as the usual proposal of GMS and therefore, it's much less dangerous.
  - deleted 9y ago
    [deleted]
- inglor 9y ago
  I'll try to elaborate, global _app_ state is different from global state "in the wild". The internet is "global state" but you wouldn't call any code that makes HTTP requests global state because the "globality" is isolated inside your app. Global can mean several things, my point was only that "globality" inside your app can (and should) be very constrainted while acknowledging some things are indeed global from your app's point of view. A good example of this is having a global "db" object vs. a DB instance passed to places. This is more about whether or not your code should care about where it gets data or not. I think this (now classic) talk is a nice explanation about why your components should not "look for things" in the global but instead should be explicit about dependencies any why it's easier to reason about: https://www.youtube.com/watch?v=RlfLCWKxHJ0 https://www.youtube.com/watch?v=RlfLCWKxHJ0

by inglor 9y ago

adrianratnapala 9y ago

I don't get this. Once you mutate the database, then the behaviour of any code anywhere that uses the DB, whether directly or through a module is potentially affected by the mutation. Modularisation is great and all, but it doesn't make concurrency and cache-coherency problems go away. In fact it sometimes makes those things worse (or at least more opaque).

wiz21c 9y ago
The database (at least the relational ones (I don't know the nosql thing)) is actually a very well behaved global state. It gives you guarantees about its mutability which you often don't have in your own code (well, in mine at least :-)). Moreover, the transactional nature of those DB actually percolates in many places in the code and makes it more reliable. So I'd say the database is a very special mutable thing, it's not as general as the usual proposal of GMS and therefore, it's much less dangerous.
- deleted 9y ago
  [deleted]
inglor 9y ago
I'll try to elaborate, global _app_ state is different from global state "in the wild". The internet is "global state" but you wouldn't call any code that makes HTTP requests global state because the "globality" is isolated inside your app. Global can mean several things, my point was only that "globality" inside your app can (and should) be very constrainted while acknowledging some things are indeed global from your app's point of view. A good example of this is having a global "db" object vs. a DB instance passed to places. This is more about whether or not your code should care about where it gets data or not. I think this (now classic) talk is a nice explanation about why your components should not "look for things" in the global but instead should be explicit about dependencies any why it's easier to reason about: https://www.youtube.com/watch?v=RlfLCWKxHJ0 https://www.youtube.com/watch?v=RlfLCWKxHJ0