Re: [off topic] - Re: Exceções, interfaces e Java

["Jorge F. Del Teglia" <PROTECTED>]

Ola Nelson,

>Legal, mas parece-me que voce ainda esta' enxergando classes e tipos como
>sinonimos; eles so' sao sinonimos em C++ e em Java.

Em realidade, só tentaba dizer que, porem a implementação interna da 
linguagem dé em algo similar, os conceitos por tras são diferentes em C++, 
Smalltalk e Java:

- Java: 'classe' implica 'tipo', mas 'tipo' não implica 'classe';
- C++:  'classe' implica 'tipo', e 'tipo' implica 'classe'. Logo, 'tipo' 
equivale a 'classe'
- Smalltalk: similar a Java, só que a verificação, como voce diz mais 
abaixo, é totalmente dinamica (em Java é estática a verificação de 
correctitude de atribuição de referências, mas dinâmico o lookup de métodos)

>A relacao de heranca
>tende "naturalmente" a permitir a "substitutabilidade", mas nao e' a unica
>forma de permiti-la. Por exemplo:
>
>class A {
>public:
>         void printnum (int i) { cout << i << endl;};
>}
>
>class B {
>public:
>         void printnum (int i) { cout << i << endl;};
>}
>
>Em smalltalk, classes com essa "cara" poderiam ser usadas uma no lugar da
>outra; em C++/Java, nao. Agora, ponha a mao na consciencia e responda:
>qual comportamento e' mais coerente? Parece-me que e' o do smalltak,
>porque *de fato* as duas classes correspondem ao mesmo tipo.

Concordo com você quase totalmente. Mas acho que finalmente chegamos a um 
ponto 'quase' filosófico entre tipação forte e fraca. Acredito que existe 
uma variável a mais que ainda não consideramos (ao menos explícitamente): o 
tipo de um objeto não está definido só pela sintaxe, mas também pela 
semántica. Dois objetos que 'aceitem' o recebimento de uma mesma mensagem 
(estática ou dinamicamente), não necessariamente pertencem ao mesmo tipo. 
Só que por simplicidade, assumimos que métodos com a mesma assinatura tem o 
mesmo comportamento. Mas não necessariamente é assim (talvez por ter uma 
modelagem não muito boa, tal vez por outra razão...).

Tal vez a invocação do método stopEngine() num objeto da classe Aviao 
produz um resultado muito diferente a stopEngine() na classe 
GeradorElétrico (em particular, um resultado algo perigoso ;-)

Alguém pode dizer que isso deve ser verificado na hora de escrever o 
código. Mas é mais robusto, se essa limitação está inserida nas 
*estruturas* do sistema e não só em como utilizamos elas. Do mesmo jeito 
que estruturar o controle de fluxo em linguagens estruturadas melhorou a 
robustez de código (em GW-Basic, também era possivel escrever código 
não-spaghetti com 'gotos', mas a estrutura não ajudava), estruturar a 
atribuição de tipos em objetos *pode* (mas não necessariamente) melhorar a 
robustez uma vez mais.

Mesmo assim, acho que é um tema não completamente resolvido e ambos 
enfoques tem suas vantagens e problemas, logo, 'Vivent les Objets!!'

Abraços,

Jorge