Comments on: Herança não funciona

By: Herança não funciona, parte III | Rodrigo Kumpera Weblog

Herança não funciona, parte III | Rodrigo Kumpera Weblog — Mon, 01 Dec 2008 14:35:20 +0000

[...] artigos anteriores eu descrevi algum dos problemas associados com herança, ou subtipagem, e questões [...]

By: Herança não funciona, parte 2 | Kumpera.net delírios sobre linguagens de programação

Mon, 31 Dec 2007 04:27:45 +0000

[...] escrevi anteriormente que herança não funciona meu objetivo não era realmente provar isso, mas atentar ao fato de que [...]

By: problemas da herança « TJRN Developers

problemas da herança « TJRN Developers — Fri, 07 Dec 2007 12:10:29 +0000

[...] post desse blog aborda sobre [...]

By: kumpera

kumpera — Sat, 24 Nov 2007 19:27:08 +0000

Marcos, classes abertas são uma limitada de meta-programação, pretendo escrever sobre isso em um artigo futuro.

Andrei, a interpretação de “type soundness” esta relacionada a correta preservação e dos tipos mediante a qualquer operação, porem não deixa de ser importante possuir um termo curto para descreve-la, ou do contrario teríamos textos de demasia dificuldade de leitura.

Mutabilidade definitivamente entra em conflito com herança. Pessoalmente, fico com mutabilidade, mesmo em vista de todas as facilidades advindo dela. Herança pode ser substituída por composição e anotação explicita de variância no caso de variáveis de referencia, tuplas ou arrays – por sinal, tuplas mutáveis são uma coisa meio bizarra.

By: Andrei

Andrei — Thu, 22 Nov 2007 05:23:28 +0000

Ah, faltou uma coisa: sobre os problemas teóricos de variância mencionados no post, eles são causados pela combinação da herança com outras características das linguagens OO, como mutabilidade de variáveis. Então em resumo teria duas soluções: remove a mutabilidade de variáveis ou remove a herança. Claro que para quem programa em linguagens OO é provavelmente mais simples tirar a herança do que a mutabilidade, mas não é necessariamente a herança que é a raiz do problema.

No capítulo sobre sub-tipos do TAPL ele formaliza arrays só para leitura e só para escrita que são corretas com relação à variância. Se isso seria utilizável em uma linguagem real, não sei. O interessante é que marcar uma variável como mutável (como acontece na família ML) poderia ter outros usos também. Mas isso já são questões de language design, divago.

By: Andrei

Andrei — Thu, 22 Nov 2007 05:03:09 +0000

Quanto a uma tradução para “type soundness”, eu não sei. Vi um dia desses em francês, uma “proof of type soundness” é “preuve de preservation de types”, que captura bem a idéia. Uma prova de type soundness é uma garantia que os tipos são preservados em cada passo da avaliação dos termos, não? (sendo que a “preservação” inclui a idéia de subsumption — tb não sei como traduzir — de sistemas com sub-tipos).

Sobre herança não funcionar, talvez seja um pouco extremo, mas certamente a herança sempre foi superestimada. Hoje em dia conselhos como “prefira composição ao invés de herança” são comuns, e pra mim é difícil achar bom um projeto com hierarquias profundas. Acredito que em alguns domínios a herança seja bem útil, embora seja possível se virar sem ela. Bem, eu tenho programado quase que exclusivamente em linguagens funcionais nos últimos tempos, e não sinto falta de nada OO. Já quando eu uso uma linguagem OO, por outro lado…

E adicione outra dificuldade causada por sistemas com subtipos: a inferência global de tipos fica indecidível. É por isso que Scala, por exemplo, usa inferência de tipos local, e é o mesmo motivo que ninguém conseguiu integrar muito bem subtipos com o sistema Hindley-Milner, até hoje. As type classes em Haskell são bem legais e podem simular herança de interfaces, mas não cria problemas de variância — e, mesmo assim, torna a inferência indecidível em geral, requerendo um maior uso de anotações de tipos no código. Eu acho interessante que, em ML (OCaml, SML) é muito raro ver código com anotações de tipos explícitas, enquanto que em Haskell isso é bem comum. Um dos motivos são as type classes.

By: Christiano Milfont

Christiano Milfont — Wed, 21 Nov 2007 12:15:16 +0000

Isso, e quanto ao prototype-based OO?
No javascript vários frameworks implementaram facilmente a herança múltipla pelas características da linguagem.
Louds, e qual seria a melhor alternativa para substituir a herança? Exemplo prático, tenho uma classe Documento em um sistema onde extendo para suas especializações como por exemplo RequisicaoVeiculo, que tem propriedades distintas a esse tipo de documento. Seria uma abordagem de composição melhor do que Herança nesse caso?

By: Marcos Silva Pereira

Marcos Silva Pereira — Tue, 20 Nov 2007 02:06:03 +0000

Rodrigo, classes abertas não são uma maneira de implementar um sistema de meta-classes? Ou vc fala de algo como o MOP de Groovy (onde há “class” e “metaclass”)?

E mais, o que vc acha de protótipos como alternativa?

valeuz…

By: Proteu Alcebidiano

Proteu Alcebidiano — Mon, 19 Nov 2007 02:28:53 +0000

Rodrigo, outra coisa que me fez lembrar indiretamente de sua postagem mais recente:

http://www.infoq.com/news/2007/11/qi4j-intro

T+

By: kumpera

kumpera — Fri, 16 Nov 2007 11:41:24 +0000

Proteu, open classes do ruby são uma ótima solução, mas eu acredito que é um recurso desnecessário na presença de um bom sistema de meta-classes.