Clarify 'and' usage in ValueUnit.Unit

[draptik]

I am wondering why the type ValueUnit.Unit uses a bunch of and.

Maybe there is a trick involved here, but I always thought that and in type definitions is only needed for recursive scenarios (tree, branch, node, containing another node, etc).
But maybe I'm missing something obvious?

Here is an example:
https://github.com/halcwb/GenPres2/blob/cf1e6a5698342c1bab97c20aff006c3fec3215dd/src/Informedica.GenUnits.Lib/ValueUnit.fs#L76

[halcwb]

@draptik: I have to admit that was how my brain was thinking at that time. Also, maybe the notion that a CountUnit as a distinct type doesn't have a real merit? So, basically this setup tries to tell that this is a hierarchical setup. Does that make sense?

[draptik]

@halcwb yes, I understand the reasoning. It makes perfect sense. But I wonder if there is a better way to express this in f#... :-)
Feel free to close this issue

[halcwb]

@halcwb yes, I understand the reasoning. It makes perfect sense. But I wonder if there is a better way to express this in f#... :-) Feel free to close this issue

I will leave this open because I don't like the code right now. So, I am very much open to improvement of the code.

[halcwb]

I think we should move all types to a seperate types module (as in the rest of the repos). But then we need to also move from static member functions for calculation to inlined functions as you cannot extend types in different modules with static members. @draptik and @mattgallagher92 what doe you think?

[mattgallagher92]

I agree that unnecessarily using and is odd. It essentially bundles the types up into one interdependent blob, which is different from the usual linear orderliness that F# imposes and that a lot of us love.

If you're using and to signify that the types are related, then putting them together in a module is more idiomatic, so that could be a good idea.

I'm not yet familiar enough with the code to give a well-informed opinion on whether moving from static member functions to inlined functions is a good idea.