-
-
Save jbrains/ff3065f4abe0d8d0a7effb8f86c1b122 to your computer and use it in GitHub Desktop.
// findPrice : String -> Option<Price> | |
// Option comes from Atlassian's fugue library https://docs.atlassian.com/fugue/4.3.0/fugue/apidocs/index.html | |
// I want the equivalent of | |
// case (maybePrice) { | |
// none => display.displayProductNotFoundMessage(barcode) | |
// some(price) => display.displayPrice(price) | |
// } | |
catalog.findPrice(barcode) | |
.<Runnable>fold( | |
() -> (() -> display.displayProductNotFoundMessage(barcode)), | |
(price) -> (() -> display.displayPrice(price)) | |
).run(); |
@gtrefs Thank you. Yes. I have a separate project in which I'm rewriting my entire teaching example with the constraint "no method expectations in the tests", which encourages me to use return values in the way that you describe here (and even pushing Display
up the call stack, where it becomes RenderResultView
). In that situation, I think of the situation as mapping Option<Price>
to Either<String, Price>
and then to Either<ProductNotFoundMessage, ProductFoundMessage>
. Now the Controller and View negotiate over who dispatches from the message alternatives to send the corresponding message text to the application's output stream.
This is not that project. I'm still using my old, OO approach (fire the right event for each outcome), but I found Fugue (and now Javaslang) intriguing, and so I'm trying to use them together. I can't tell whether the libraries are missing something useful or they're telling me that these types and the fire-event approach are fundamentally incompatible. That's one of the things I'm learning.
My two minutes attempt, using Functional Java. Obviously, untested and from the top of my head!
/*
* Assuming:
*
* barcode :: Barcode
* display#displayProductNotFoundMessage() :: F<Barcode, IO<Unit>>
* display#displayPrice() :: F<Price, IO<Unit>>
*/
catalog.findPrice(barcode) // Option<Price>
.map(display.displayPrice()) // Option<IO<Unit>>
.orSome(
display.displayProductNotFoundMessage().f(barcode) // IO<Unit>
)
.run();
If the only side effect is printing a String, we could simplify it like this:
/*
* Assuming:
*
* barcode :: Barcode
* display#displayProductNotFoundMessage() :: F<Barcode, String>
* display#displayPrice() :: F<Price, String>
*/
String res = catalog.findPrice(barcode) // Option<Price>
.map(display.displayPrice()) // Option<String>
.orSome(
display.displayProductNotFoundMessage().f(barcode) // String
);
fancyPrint(res);
You are welcome. Glad that I could help :).
The code looks fine to me 👍 The docs say that you should use
run
if you want to perform side effects with pattern matching (see http://www.javaslang.io/javaslang-docs/#_the_basics_of_match_for_java). In my example, the display functions where not real commands, as they also returned aString
. I think Nat Pryce already mentioned, that your code is a mix between imperative and functional. I would rather useMatch
as an expression and let it return the value which should be displayed (for example, a value type ofMessage
), but I don't know which design you want to achieve. I would do something like this:But that is my inner techie speaking and as I said, I don't know what design you are seeking for.