wireapp / wire-server

🇪🇺 Wire back-end services
https://wire.com
GNU Affero General Public License v3.0
2.6k stars 327 forks source link

Clean up Wire.Subsystem module structure #4081

Open fisx opened 1 month ago

fisx commented 1 month ago

https://wearezeta.atlassian.net/browse/WPB-9597

(inspired by https://wearezeta.atlassian.net/browse/WPB-8880)

Checklist

MangoIV commented 3 weeks ago

I have a couple of questions:

I somehow like the idea of a flatter directory structure so I think that UserSubystem is nicer that Subsystem.User but also it feels like it doesn't adhere to the conventions; perhaps we could even do WireSubsystem if we don't adhere to them anyways?

akshaymankar commented 3 weeks ago

Could you please write about the motivation for this work, nothing in JIRA or README or the PR description seem to have it captured, so its hard to even engage with this PR. Still here are somethings that could make it better:

  1. I think instead of the tree output we could put slightly more effort into just listing the module namespaces which matter most and write about them, the tree output is just noisy for most part.
  2. Calling things Subsystem.User instead of UserSubsystem makes a lot of files in the code being called User.hs and (fuzzily) searching for them is a pain (also most editors just show file names when there are multiple buffers or tabs are open), so I also prefer UserSubsystem from dev-ex perspective.
  3. I also don't have very strong conviction about which things are Subsystems and which things are not (specially the not part). If we cement things down with this directory structure now, it feels a bit premature, I think we should work on defining those first (or perhaps spend some more time with this to get the sense).

All said, it would be best to first define our reasons for this then spend more time into it if we feel its justified.

fisx commented 3 weeks ago
  • are we going to update the output of tree every time we're modifying the subsystem? how are we verifying that?

no, we'll either keep it as an incomplete sample, marking it as such, or remove it entirely. it's not that hard to look for yourself after all. i just put it there for now so people can see what i mean.

  • why is it called Eff? I think it's misleading, many effect systems call their monad Eff.

no strong opinion / open to suggestions. the reason was that Eff interpreters only implement one polysemy effects in terms of others, so it's not cassandra, but a polysemy Effect underneath.

what about Polysemy?

  • why is it called Mem? Wouldn't InMemory convey the semantics better?

sure, InMemory is at least as good. i'll take it, thanks! :)