Newest at the top
| 2026-02-09 22:06:11 +0100 | <EvanR> | immutable objects is kind of fashionable these days |
| 2026-02-09 22:06:10 +0100 | <jreicher> | I would suggest you're not really doing OO in that case. It's an opinion I'm not even sure I believe, but I just don't see OO offering anything special if its state mutation facilities aren't being used. |
| 2026-02-09 22:05:35 +0100 | <EvanR> | you can get pretty far in OOP without mutability |
| 2026-02-09 22:05:30 +0100 | <jreicher> | Is it what? |
| 2026-02-09 22:05:15 +0100 | <EvanR> | is it? |
| 2026-02-09 22:04:30 +0100 | KindFoxo | (~KindFoxo@user/KindoFoxo) KindoFoxo |
| 2026-02-09 22:04:25 +0100 | <jreicher> | Yes the mutability of objects is a key point, because the representation of state and the way it's mutated is exactly the kind of implementation detail that clients don't want to know. So I don't think an FP equivalent (if there is one) would just be passing parameters. |
| 2026-02-09 22:04:14 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2026-02-09 22:03:54 +0100 | KindFoxo | (~KindFoxo@user/KindoFoxo) (Remote host closed the connection) |
| 2026-02-09 22:03:36 +0100 | <geekosaur> | or monads |
| 2026-02-09 22:03:23 +0100 | <geekosaur> | OOP smuggles parameters in objects. Haskell can smuggle them in contexts. ☺ |
| 2026-02-09 22:02:41 +0100 | <geekosaur> | note however that it's controlled not by actual need but by perceived need, and perceptions can be slower to change |
| 2026-02-09 22:01:42 +0100 | <EvanR> | in FP |
| 2026-02-09 22:01:32 +0100 | <EvanR> | it's one of several OOP things which boils down to "pass a parameter" |
| 2026-02-09 22:00:12 +0100 | <jreicher> | I've never tried to transplant it to FP. There are certainly people who believe it's very, very important in OO. |
| 2026-02-09 21:59:20 +0100 | <EvanR> | dependency injection sounds verbose and redundant on the face of it, but maybe that's important xD |
| 2026-02-09 21:59:09 +0100 | <geekosaur> | it certainly changes over time |
| 2026-02-09 21:58:39 +0100 | <EvanR> | is jargon darwinistic, i.e. does it persist and expire based on fitness for its purpose, recognized or not xD |
| 2026-02-09 21:56:51 +0100 | <EvanR> | a couple lines of code is worth N full months of arguing |
| 2026-02-09 21:56:09 +0100 | <jreicher> | ...a full month... |
| 2026-02-09 21:56:01 +0100 | <jreicher> | I spent probably full months arguing with some friends about exactly what "dependency injection" meant, and more than half of that was trying to figure out what a "dependency" is. |
| 2026-02-09 21:55:36 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-02-09 21:50:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-09 21:50:47 +0100 | <c_wraith> | I did some funny stuff faking dependent instances using a Reifies constraint. It works, but actual dependent types would be a lot easier to use. |
| 2026-02-09 21:50:45 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 245 seconds) |
| 2026-02-09 21:44:53 +0100 | <c_wraith> | Which has interesting UX considerations |
| 2026-02-09 21:44:34 +0100 | <c_wraith> | functionally, the reflection library is also just "passing parameters", except it smuggles the parameter in a class constraint. |
| 2026-02-09 21:44:03 +0100 | <EvanR> | which I guess has the proper name Implicit Configurations |
| 2026-02-09 21:44:02 +0100 | KindFoxo | (~KindFoxo@user/KindoFoxo) KindoFoxo |
| 2026-02-09 21:43:56 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-02-09 21:43:42 +0100 | KindFoxo | (~KindFoxo@user/KindoFoxo) (Ping timeout: 265 seconds) |
| 2026-02-09 21:43:36 +0100 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-02-09 21:42:13 +0100 | <EvanR> | see also reflection (in haskell, for getting similar things accomplished) |
| 2026-02-09 21:40:42 +0100 | <c_wraith> | Just for compatibility with different library versions renaming modules. |
| 2026-02-09 21:40:27 +0100 | <c_wraith> | I actually use backpack features, but not for parameterized modules. |
| 2026-02-09 21:40:10 +0100 | <ncf> | oh |
| 2026-02-09 21:40:04 +0100 | <dolio> | backpack |
| 2026-02-09 21:39:59 +0100 | <c_wraith> | Also, I guess it's more that *cabal* has them, and will modify the compilation environment to synthesize the equivalent. |
| 2026-02-09 21:39:54 +0100 | <ncf> | does it? |
| 2026-02-09 21:39:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2026-02-09 21:39:18 +0100 | <c_wraith> | technically Haskell has those, but they're so painful that no one uses them. |
| 2026-02-09 21:37:29 +0100 | <ncf> | i guess this is only necessary in a language without parametrised modules.. |
| 2026-02-09 21:34:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-09 21:34:29 +0100 | <c_wraith> | There are a lot of ways to do this, of course. But a single indirect function call is very low weight, compared to a lot of abstractions you can come up with. |
| 2026-02-09 21:32:01 +0100 | <c_wraith> | They key point is that you've abstracted managing the log system away from the logic that actually sends messages to the log system. |
| 2026-02-09 21:31:08 +0100 | <c_wraith> | It's not necessarily continuations. You can pass around `log :: Env -> Level -> Message -> M ()' and there's no continuations there. |
| 2026-02-09 21:31:07 +0100 | <EvanR> | https://academy.fpblock.com/blog/2017/06/readert-design-pattern/ |
| 2026-02-09 21:30:11 +0100 | <ncf> | sounds like that's what this is, unless i'm misunderstanding what it is people call the "ReaderT pattern" |
| 2026-02-09 21:29:45 +0100 | <EvanR> | if your dependencies are continuations |
| 2026-02-09 21:29:27 +0100 | <ncf> | although maybe continuation-passing would be a better name for this |