O método que não existe

O check acusava p.clientte num record e calava em "ana".naoExiste(). A conferência agora vale para os dois, e a lista de métodos é lida do interpretador.

A forma mais comum de erro de digitação numa linguagem é chamar um método que não existe. O dataforge check acusava isso num record e num blueprint — com sugestão — e calava num texto, num cluster e num vault.

A medida#

Quinze erros que falham em execução, conferidos contra o que o check pegava antes de rodar. Ele pegava oito. Dos sete silêncios, quatro eram este mesmo caso em tipos diferentes:

nome := "ana"
xs := [1, 2, 3]

// Os dois abaixo sao acusados agora, com sugestao:
//   nome.uppper()   ->  'String' has no method 'uppper'
//                       sugestão: Você quis dizer 'upper'?
//   xs.apend(3)     ->  'Cluster' has no method 'apend'
//                       sugestão: Você quis dizer 'append'?

assert nome.upper() is "ANA"
xs.append(4)
assert len(xs) is 4
out "o mesmo erro, o mesmo tratamento"

A lista vem do interpretador#

As tabelas de método de texto e de cluster moram em dataforge/interpreter.py, e o analisador as lê de lá. Uma segunda lista divergiria no primeiro método novo — e a divergência não daria erro: ela faria o analisador acusar um método que funciona, que é o falso alarme que ensina a desligar a verificação.

Onde ele cala, e por quê#