For collections, returning [] (empty collection) instead of null is almost always what I want.
Maybe Functions
91–100 of 103 posts
Re: Maybe Functions
#92this is basically like bubbles under wallpaper - the "maybeness" is not due to your code, but due to the underlying problem you are solving (a user can either be logged in or not, and if they are not then all user properties are null). the article identifies the problem with various solutions as extra layers of abstraction, but i feel like the real issue is ceremony - whether propagating maybe-coloured functions through your code and checking the return value everywhere, or wrapping everything in a monad, you have to do something to handle the null case when all you really care about is the non-null case, and that something inevitably feels like clutter and overhead.
Re: Maybe Functions
#93That's not a monad, that's just a functor. And that's great, because functors are easier to grok than monads! A functor F consists of two things:
- a kind of function on types which transforms any type T to some new type F(T)
- a rule which associates to any function f: T -> S a function fmap(f): F(T) -> F(S)
That's exactly what the author defines here, to a type T we associate Maybe, and to a function f: T -> S we associate `fmap(f)(x) = None if x is None else f(x)`.
A monad needs some structure in addition to fmap, namely bind and return. These allow you to take a function T -> F(S) and a function S -> F(U) and compose them together to a function T -> F(U).
Re: Maybe Functions
#94That's not a monad, that's just a functor. And that's great, because functors are easier to grok than monads! A functor F consists of two things: - a kind of function on types which transforms any type T to some new type F(T) - a rule which associates to any function f: T -> S a function fmap(f): F(T) -> F(S) That's exactly what the author defines here, to a type T we associate Maybe , and to a function f: T -> S we…
[deleted]
Re: Maybe Functions
#95Agreed with this essay, and I think it rhymes with two others that I've found pretty influential over the past five years: 1. Parse, don't validate ( https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... ) 2. Pipeline-oriented programming ( https://fsharpforfunandprofit.com/pipeline/ ) In my experience, the "best" code (defining "best" as some abstract melange of "easy to reason about", "easy to modify", "e…
Good concepts (although too few text on the slides on the second link)
Re: Maybe Functions
#96Earlier quoted context omitted.
Interestingly, Python uses exceptions for basic control flow, like end of for-loop.
Well it uses exceptions in the case your generator is at the end, not usually at the end of a for loop because a for loop by definition iterates over a list until the list is finished. The exception actually occurs when you call next() on a generator which cannot return any more values, or is finished, in which case `StopIteration` is usually raised.
All Python iterators raise StopIteration at the end of iteration. For-loops always use the iterator protocol. Neither generators nor lists are special in this regard.
>>> next(iter([]))
Traceback (most recent call last):
File "", line 1, in
StopIteration
>>> next(iter((lambda: (yield 5) if False else None)()))
Traceback (most recent call last):
File "", line 1, in
StopIterationRe: Maybe Functions
#97I feel like this isn't really a general statement on maybe functions but unnecessary maybe functions. If you can make it not "maybe" but "always" then of course that's obviously better.
The real use case is when it really is maybe. (Network call, error handling). Then it's about forcing people to deal with that in a typesafe way and not hiding that it really is maybe.
Re: Maybe Functions
#98Earlier quoted context omitted.
I am for exceptions but it should not be used for basic control flow. Many techs will treat all exceptions as errors.
Interestingly, Python uses exceptions for basic control flow, like end of for-loop.
Semantically, Python separates Exceptions and Errors. The mechanism for throwing and catching them is the same.
Here's a quick description from somewhere on the interwebs: An error is an issue in a program that prevents the program from completing its task. In comparison, an exception is a condition that interrupts the normal flow of the program.
Then there is StopIteration, which does not fit well into either of the two above. It's a wart I've learned to treat as a beauty mark.
Re: Maybe Functions
#99I think that naming functions with a prefix of maybe is awful. I treat all functions as "maybes".
Re: Maybe Functions
#100Earlier quoted context omitted.
for a function called "getUser" it is.
Not exactly. "getUser" not having a user to get is not exceptional unless you only have logged in users. If you have logged-out users, then "getUser" should gracefully handle the case of an unknown, logged-out user (either returning null or some other sentinel value).
Returning null makes "getUser" a "maybeGetUser" function.
Like said in TFA that means that any caller might need to check for nullness