dunai
: Re-structure API: InternalCore
and Util
#354
Replies: 4 comments
-
It could also make sense to have all those separate modules without |
Beta Was this translation helpful? Give feedback.
-
What I like about this second way is that, instead of |
Beta Was this translation helpful? Give feedback.
-
1.-3. makes sense to me
If they require
We are talking about 6 items in total split up into 4 groups. Is this hierarchy really necessary? Why not put them all in one package
I don't think dunai is large or bloated enough (and probably won't be in the near future) to justify a separate library which would make everything scattered and hard to get an overview of. |
Beta Was this translation helpful? Give feedback.
-
For now.
That's the idea behind putting them under From the point of view of the user, the distinction between
There are other criteria that are also important and that I'm trying to take into account here. One of them is to use libraries to delimit layers of abstraction. Having a good design (including a good separation into libraries) will decrease the maintenance burden and facilitate understanding dunai as a whole. |
Beta Was this translation helpful? Give feedback.
-
An issue that has been bugging me for some time is that there are multiple modules at the same level in dunai with disparate functionality. currently, we publish:
These modules can roughly be grouped as follows:
To me, the fact that they are all listed at the same level makes following all of this hard. I believe one has to keep these groups in their head and, although it's possible, it should be obvious to the user and the maintainer, to minimize the mental burden of using dunai.
In particular, the fact that
Core
andInternalCore
are separate, and the fact that everything under number (4) is scattered around, just adds noise to the API.The first issue has a solution: rename
Data.MonadicStreamFunction.InternalCore
toData.MonadicStreamFunction.Core.Internal
. That's also fairly common practice.I can't think of a way to group everything under (4) that is not ugly. I'd welcome ideas in this regard.
We do not want to put everything in
Util
directly. Importing the internal core should generally be avoided, and we are likely to get lazy and take shortcuts if we open that Pandora's box. It's useful to keep those separate (and, if we can, re-implement them withoutInternalCore
), and it is telling us something about MSFs themselves.A possibility would be to put everything under
Util
, and re-export it from there. To avoid circular imports (Async
importsUtil
), we could just splitUtil
into smaller modules.There's also a chance that we need to split dunai into two or even three separate libraries (e.g.,
dunai-core
,dunai
proper, anddunai-contrib
).EDIT: Re-sort paragraphs.
Beta Was this translation helpful? Give feedback.
All reactions