View a recipe in another unit system

[luxmiranda]

View a recipe in another unit system

[LuxMiranda]

Great work! Herm's uses a library called optparse-applicative to handle all of the flags. I'm not actually super familiar with it; @vrom911 is our resident expert there :)

[LuxMiranda]

Thanks @vrom911 !

Some good ideas, but I think that perhaps a wiser option would to have something like this:

data Conversion = Metric | Imperial | None

By default recipes could simply be labeled None and not attempt to convert themselves. Only when passed a flag like -i|--imperial or -m|--metric would the recipe be converted and shown. That way, users with nothing but metric recipes don't have to type --metric every time they want to view a recipe. :)

[nasanos]

I'll get started on this, if no one else has taken it, starting with the functions involved.

After looking over Types.hs, my impression is that UnitConversions.hs could maybe consist of two functions:

• A function converting metric units to imperial,
• A function converting imperial units to metric.

This would also result in all units, after the conversation, being of the same system.

Alternatively, this could be accomplished on a case-to-case basis, with a function for each unit:

• A function for tsp,
• A function for Tbsp,
• A function for mL,
• Etc.

This approach might be a little trickier, but it would give more control over the conversion implementation.

[nasanos]

My current pull request (34) doesn't solve all of the issues proposed here, but I think it gets a start in place, which I plan to continue on as time allows.

I was wondering if you could give me a rundown of how Herms uses flags. Hopping through the files still left me unsure of best-practices for implementing flags for the unit conversions.

[vrom911]

@nasanos nice work so far! 🥇
Flags handling is actually very easy now with usage of optparse-applicative ☺️
All code related to it is in Main module here.
But first of all I suggest you to replace check of 1 or 0 to proper data type. Something like this:

data Conversion = Metric | Imperial

This will make code safer and easier to read and understand. But not only, this also will help to make adding flag process much easier and painless.
But first let me clarify how we want the flag to be?
I vote for having default conversion as Imperial and change it to Metric only when flag -m|--metric (or any more convincing name) is present. If this is the case all you need is to write conversionP :: Parser Conversion which will be the flag.
Probably it's not the best choice, your suggestions are more than welcome. It's usually the hardest part to create the architecture of how it should be..
Anyway, if you have any questions I'm always happy to answer 🙂

[nasanos]

So, it looks like this would take two flags, one for metric and one for imperial. I didn't see a way in the optparse-applicative docs to handle this otherwise, but correct me if I'm missing something there.

[vrom911]

@JackKiefer @nasanos if we have now more than two cases it is not going to be switch anymore. I guess in this case in will be more comfortable for usage purposes to have something like [--system SYSTEM_TYPE]. And when you need to turn on any just type herms view --system metric for example.

Also the good point of this choice is that in the future you would be able to add more metric systems without rebuilding the architecture and making number of options really crazy :)

UPD.: also the options that you wrote about in previous point makes this command possible

herms view --imperial --metric

which is a bit confusing..
What do you think guys?

[ppartarr]

I believe this should be closed since the -convert flag was merged in #38

[langston-barrett]

I agree. Let's follow up with other issues if there are still remaining tasks.