Não há problema com isso. Em linguagens que não possuem variáveis digitadas, é isso que acontece em todas as funções. Parâmetros formais são apenas valores, e o tipo está no objeto que é passado, não no parâmetro formal.
People Get Stuff Feito (TM) em Lisp, Python, Ruby, ...
Embora você se beneficie menos da verificação do tipo de tempo de compilação, também sofre menos com a verificação do tipo de tempo de compilação.
A solução real é usar alguma linguagem dinâmica que tenha como alvo a máquina virtual Java, em vez de escrever código Java feio em que cada terceiro identificador é a palavra Object .
Eu faz sentido ter uma função completamente genérica chamada construct , que aceita objetos arbitrários.
Acho que gostaria de colaborar com este programador. Levaria um pouco da picada de usar uma linguagem de programação macabra.
Observe que esse tipo de código ocorre em C na implementação do suporte em tempo de execução para linguagens dinâmicas implementadas em C. E.g. você pode ver algo assim em um Lisp implementado em C:
/* Map each object in a list through a function, in order to produce
a list of the return values. */
val mapcar(val function, val list)
{
val iter = car(list);
val out = nil; /* nil is really a null pointer */
for (iter = car(list); iter; iter = cdr(iter))
push(funcall_1(function, car(iter)), out); /* push is a C macro */
return nreverse(out); /* destructively reverse list */
}
O tipo val é realmente algo como:
typedef struct object *val;
e struct object é uma estrutura complicada que sobrepõe vários tipos de informações de tipos para vários tipos de objetos.
Desenvolvi uma linguagem de programação muito agradável, cujos elementos internos são todos feitos neste estilo, que eu mantinha deliberadamente o mais limpo possível: mais do que nos aspectos internos de alguma outra implementação de linguagem que adotam uma abordagem semelhante.
Neste estilo, coisas incríveis são possíveis em uma pequena quantidade de código C.