Boa noite povo!
Continuando com a décima primeira parte da tradução de “A Formal Language for Analyzing Contracts”. No último versículo vimos a décima.
Máquinas de Conexão
Mostrando ainda mais a flexibilidade de nossa linguagem, podemos adicionar sensores e efetores, acrescentando “inteligência” a nossos contratos e aumentando a aplicação legal com restrições tecnológicas.
Primeiro, esboçamos uma especificação para o comportamento de contrato de uma máquina de venda automática:
sellCandy(candyPrice = $0.90) =
variable moneyAmount = $0.00
then
# coins also fall into a temporary till tempTill
when (nickel)
add(moneyAmount, $0.05)
when (dime)
add(moneyAmount, $0.10)
when (quarter)
add(moneyAmount, $0.25)
when (moneyReturn)
dropCoins(tempTill, returnTill)
with moneyAmount = $0.00
when threshold(moneyAmount, candyPrice)
when (nickel | dime | quarter)
redirectNewCoinsTo(returnTill)
also display(“ready to dispense — please select candy”)
then when (candySelection)
dropCandy(candyRacks, candySelection)
with dropCoins(tempTill, permTill)
with moneyAmount = $0.00
continue
Introduzimos aqui um novo recurso de linguagem, uma variável de estado. Nossa variável de estado moneyAmount gera um evento ao ultrapassar o limite de preço de doces de $0,90. Observe que nickel [moeda de 5 centavos], dime [moeda de 10 centavos], etc. são objetos físicos reais que os sensores (gerando eventos “nickel“, “dime” etc.) detectam e tratam separadamente – não são apenas quantias abstratas de dinheiro.
Variáveis de estado podem ser problemáticas e devem ser evitadas, a menos que seja absolutamente necessário, como aqui. Esta é relativamente inofensiva porque o slot de moedas tende a forçar as moedas a entrar uma de cada vez, de modo que não há duas cláusulas tentando alterar a variável de estado ao mesmo tempo. Mesmo se fossem, a operação de adição é o que os matemáticos chamam de “comutativo”, o que significa que não importa em que ordem é feita. Mas se a operação na variável de estado fosse mais complicada ou envolvesse certos outros tipos de operações, não saberíamos se seria comutativo. A ordem em que os eventos ocorreram e alteraram a variável de estado pode importar muito, e poderíamos ter grandes problemas. Portanto, evite variáveis de estado sempre que possível.
Para simplificar, deixamos de fazer troco- nossa máquina precisa ter um desses sinais que você vê às vezes, “somente troco exato”. Se o cliente coloca uma moeda que empurra o valor de, por exemplo, $0,80 a $1,05 – lamento, a máquina o come. Se o cliente colocar US $ 0,90 (ou mais) e adicionar mais moedas, no entanto, a máquina retornará automaticamente as moedas extras. A máquina também retornará tudo o que foi colocado no caixa, se o cliente mudar de idéia e decidir não comprar o doce. Exercício para o leitor: verifique por si mesmo que as descrições de comportamento acima estão corretas conforme o código é escrito.
RedirectNewCoinsTo(returnTill) faz com que outras moedas caiam na rampa de retorno em vez de no sensor que aciona os eventos acima. O leitor deve aqui imaginar como é o mecanismo, pois parte do comportamento é “codificada” em seu mecaninismo, e não explicitamente nesta afirmação.
Pense nos contratos e direitos aninhados como uma árvore invertida – uma hierarquia de cláusulas aninhadas. Os eventos se propagam de cima das “folhas” da árvore em direção à “raiz” no topo. Eles são pegos pelo primeiro evento when que encontram para aquele evento. Nesse caso, uma vez inserida a cláusula when threshold(), a cláusula when (nickel | dime | quarter) substitui as cláusulas when (nickel) e assim por diante acima delas.
Como uma perpetuidade, nossa máquina de venda automática não tem horário ou condição agendada para a execução – portanto, temos uma instrução continue para substituir o implícito then terminate na última linha.
Infelizmente, nem eu nem os fabricantes de máquinas de doces do mundo real temos nenhum código para resolver o caso em que os doces ficam presos na máquina.
Terminada a décima primeira. No versículo seguinte: parte 12. Ricas bençãos!
