Maybe Functions

Nature of funções “maybe”

• Muitos leitores reconheceram que frequentemente escrevem funções “maybe” que às vezes não fazem nada ou retornam null, e acharam a crítica útil.
• Outros argumentam que o artigo confunde duas coisas:
  • Funções cujo comportamento está oculto / é inconsistente com seu tipo (por exemplo, não agir silenciosamente quando não está logado).
  • Funções que precisam às vezes falhar (por exemplo, parsing, usuário deslogado) e, portanto, nem sempre podem retornar um valor.
• Vários comentaristas acham que o verdadeiro problema são assinaturas de funções que mentem e verificações ocultas de estado global, não a opcionalidade em si.

Alternativas: exceptions, nulls e opções explícitas

• Alguns defendem exceptions para informações de “por que não” em vez de null, mas outros criticam exceptions por serem invisíveis nas assinaturas de tipo e fáceis de passar despercebidas pelos chamadores.
• Há debate sobre o que é “excepcional”: “usuário não está logado” é fluxo normal ou erro? As opiniões diferem conforme o contrato da função.
• Muitos preferem tipos de retorno opcionais/nuláveis explícitos (T | null, Option<T>, estilo TryParse) para que os chamadores sejam obrigados a tratar a ausência.
• Para coleções, retornar listas vazias em vez de null é amplamente favorecido. O padrão Null Object é visto como ocasionalmente útil, mas perigoso quando esconde falhas reais.

Sistemas de tipos, monads e suporte da linguagem

• Vários comentários conectam o tema a “Maybe vs null”, “parse, don’t validate” e programação orientada a pipeline/railway: modelar falhas como tipos de primeira classe e empurrar o tratamento para cima na stack.
• Múltiplas pessoas observam que o “Maybe” do artigo é apenas um funtor (map) e não uma monad completa (faltando flatMap/bind).
• Há discussão sobre como monads/Options se tornam “infecciosos”: uma vez introduzidos, muitas funções precisam lidar com eles. Linguagens com açúcar sintático (? em Rust, do-notation em Haskell, optional chaining) tornam isso agradável; em JS/Java/Go pode ser desajeitado.

Padrões de design e estruturação de estado

• Forte impulso para mover verificações de login/validade para as bordas:
  • Usar parâmetros explícitos de sessão/LoggedInUser em vez de estado global.
  • Garantir que funções que assumem pré-condições recebam argumentos que as codifiquem, evitando comportamento “maybe” interno.
• Alguns veem a proliferação de funções maybe como sinal de mau design do grafo de chamadas e de estado global espalhado.

Desacordos e pragmatismo

• Alguns rejeitam uma proibição absolutista de funções maybe, citando padrões como maybeShowReminderDialog como práticos e DRY.
• Outros enfatizam falhar rápido (crash ou rejeição em tempo de compilação) para erros do programador, em vez de um tratamento maybe excessivamente defensivo.