Fork me on GitHub

Would it be possible to make manifold an optional (provided?) dependency in byte-streams? I feel dirty for pulling in half a ton of dependencies when I don't think I'm using async stream transformations at all


Something along the lines of splitting the manifold-dependent pushback stream conversions into a separate namespace and only loading them if manifold is on the classpath

Matthew Davidson (kingmob)04:11:14

Well, depending on your conversion pathway, you might still be using manifold internally. Regardless, it could be done, but not easily. The pushback-related code isn't the real problem. Conditionally compiling the relevant def-conversion s wouldn't be too hard either. No, the issue is the code isn't very polymorphic, so we'd have to weave a lot of conditional compilation macros through various functions. Also def is a special form, and doesn't play too well with conditional compilation macros, iirc.

Matthew Davidson (kingmob)04:11:03

Requiring users to know they have to supply manifold is a breaking change, anyway. I would however, be fine with factoring the code out into sub-libraries, as long as the byte-streams API is the same. Then you could use the sublibrary

Matthew Davidson (kingmob)04:11:56

(Btw, we have a #C02H9GF74CF channel for this)

Matthew Davidson (kingmob)04:11:19

@UAEH11THP I don't have the time to tackle this, but byte-streams could use modernization, and this could be part of it. If you want to separate them, I could work with you on it.


Do you imagine something like the way many modular metosin projects are organized? Having a core without the manifold dependency, a module with manifold and then having the "old" top-level library pull in all those?

Matthew Davidson (kingmob)05:11:59

I'm not that familiar with the metosin layout, but yes, something like that


what's up with the branch? it looks very diverged from master