Fork me on GitHub
#funcool
<
2015-12-02
>
jaen15:12:26

Is it just me or is there no convenience functions to create Maybe or Either from something potentially nullable?

niwinz15:12:16

Can you give any example of that you are doing?

jaen15:12:33

Basically something like this:

(let [result (something-that-might-return-null ...)]
  (if result
    (just result)
    (nothing)))

jaen15:12:54

And that's quite verbose and I was wondering if I was missing a convenience function that could encapsulate that

jaen15:12:53

(and something analogous for Either where you would specify the Left value if the result was nil)

niwinz15:12:32

I agree for Maybe but not for Either

niwinz15:12:12

That behavior for either is too much opinionated

jaen15:12:00

Well, I partly agree that Either is more semantically rich than Maybe here and there's more reason to handle both Right and Left by hand

niwinz15:12:24

the cats.monad.exception already provides a "Either" analogous abstraction just for succes and failure and also provides a try-on macro that allows easy wrap any result in a proper type

niwinz15:12:47

(exc/try-on (somethird-party-fn-that-raises-exceptions))

dialelo15:12:02

note that nil already participates in the Maybe abstraction, is equivalent to Nothing

niwinz15:12:22

I forgot about it...

niwinz15:12:47

for use that you just need to (require '[cats.builtin])

jaen15:12:25

And then I don't have to wrap it by hand every time? I see.

niwinz15:12:59

no, I think we should create the analogous try-on macro for maybe for that...

niwinz15:12:29

the nil is treated as nothing, but any other value is not treated as Just...

jaen15:12:17

I see, I'll just keep doing the manual wrapping for now then

niwinz15:12:48

We surelly add the helper for the next version

dialelo15:12:46

we could call it ensure-maybe, its behavior will be similar to core's ensure-reduced

jaen16:12:32

Since you already have maybe/from-maybe then maybe to-maybe or from-nullable could be a good choice as well?

dialelo16:12:07

I dig to-maybe 👍, happy to merge a patch with these additions

dialelo16:12:11

I've opened an issue to not forget about it https://github.com/funcool/cats/issues/133

niwinz16:12:52

to-maybe is ok, but I'm will be more happy with something like try-on naming

niwinz16:12:14

to maybe is just a conversion, but I think it can be a macro

niwinz16:12:26

just for avoid additional call stack frame

niwinz16:12:50

or provide the two variants, macro and function

niwinz16:12:54

that is possible in cljs...