As pedras dos templos antigos sabem falar, mas poucas pessoas as ouvem. O universo está cheio de sons que nós, humanos, não ouvimos; cores que não vemos: às vezes são as limitações objetivas do corpo e do espírito, mas também existem razões subjetivas - falta de conhecimento e habilidades ou incapacidade de usá-las na prática cotidiana. Um exemplo vívido do segundo no mundo da programação - assinaturas de funções. As crianças do mundo OO, na melhor das hipóteses, pensam em interfaces - isso é próximo, mas "não é bem isso" e quanto mais você se torna atento, mais ele se transforma em "nada". E assinaturas de função também sabem como falar.
Honestamente, gostaria de começar do lado de abstrações verdadeiramente de alto nível, mas minha experiência anterior mostra que mesmo as verdades matemáticas mais simples de uma linguagem não matemática “não soam”. De passagem, observo que tudo do que estou falando nasce do pensamento matemático - e, portanto, pode ser formalizado estritamente.
E agora - os detalhes. Provavelmente todos mais ou menos "remexidos" se preocupam em ler pelo menos uma vez o trabalho de época do GoF; provavelmente até os que não aderem sabem que existe esse padrão - iterador. E certamente todo mundo usa todos os dias. Então (mantendo C # condicional):
bool MoveNext(); T Current { get; }
... e agora a mesma coisa, mas sem ruído sintático (é indicativo que, na verdade, "sem ruído sintático" significa em Haskell):
MoveNext :: () -> Bool Current :: () -> t
... esquecendo-se dos tipos por um tempo e concentrando-se na própria flecha (->), você involuntariamente se pergunta o que acontecerá se ela for "invertida"? Então acontece:
MoveNext' :: Bool -> () Current' :: t -> ()
Uma leve sensação de desarmonia, certo? Se não houver problemas com
t -> () , então
Bool -> () parecerá mais do que suspeito. E, de fato - essa bandeira foi usada para sinalizar o fim da sequência, certo? Na forma invertida, o caso
True -> () não faz nenhum sentido útil - apenas
False -> () é suficiente. A incerteza binária que o tipo Bool fornece é perdida - e, portanto, deve ficar assim:
completed :: () -> () next :: t -> ()
Não se parece com nada? E
as extensões reativas ?
Uau! A assinatura (bem, mais precisamente, as assinaturas, mas a própria abordagem funciona em um nível individual) da função de uma (quase) legal (mini) estrutura nos contou sobre outra não menos legal, certo? Você só precisa ter cuidado e ouvir.
Boas Novas ao Mundo da Teoria da CategoriaQuem no assunto, é claro, sabe que o exemplo com IEnumerator <-> IObserver não é novo.
É surpreendente que raramente alguém saiba que este está longe de ser o único exemplo (embora devamos prestar homenagem, especificamente este é muito brilhante).
Pessoas curiosas podem pegar os padrões restantes do GoF e analisar seus duais. Muitas vezes, um absurdo completo acontece - isso é normal: em si mesma, a “dualidade” é superior ao mundo terrestre e não se considera obrigada a considerar o uso prático: mas, afinal, o Sol também não precisa de nada das pessoas para brilhar.
Por que então "quase legal"? Sim, por causa da desarmonia que levou à necessidade de moer e cortar ainda mais. A rigor, ao girar as setas para trás, resultou em algo não muito útil, que pode ser interpretado como uma desvantagem da assinatura original. Olhando para o futuro, direi que essa assinatura pode ser redefinida de tal maneira que a desarmonia desaparece e será bastante simples voltar à sua dupla. Mas não vou me preocupar com isso ... pelo menos - não nesta nota.
Melhor resumir, baseado inteiramente na minha experiência:
- As assinaturas de funções podem falar, mas os programadores geralmente são surdos.
- Sempre que encontrar uma função bem projetada, pergunte-se qual é a sua dualidade e se ela pode ser útil para qualquer tarefa.
- Se um dual existe, mas requer uma "pequena modificação", como no exemplo acima, provavelmente a assinatura original tem alguns defeitos implícitos; talvez faça sentido redefini-lo para que não haja esse problema?