D: A D não é exatamente uma novidade, já faz uns anos que ouvi falar dela pela primeira vez. A atual versão é que é nova.

Para quem programa hoje em C++, D é um grande investimento. É multiparadigma (procedural, orientação a objetos, templates, etc.), suporta todos os recursos do C++ como embeded ASM, etc. e acrescenta muitas outras facilidades, como suporte direto a coleta de lixo automática (até que enfim!!). Em suma, a migração vale muito a pena.

Mas, para quem *não* trabalha com C++ hoje, D oferece muito pouco, na verdade.

Seu código é apenas parcialmente portável ("portabilidade de código-fonte" como C++) e esse quesito promete piorar quando empresas como a Microsoft ou IBM começarem a adicionar suas APIs proprietárias.

Sua capacidade multiparadigma é um convite para códigos híbridos confusos (coisa que os programadores da nova geração, como os javeiros, desejam abolir de sua vida).

A possibilidade de incluir código assembly pode deixar uma rotina mais rápida e eficiente, mas amarrar um sistema a uma determinada plataforma de hardware.

Conclusão: D incorpora novidades desenvolvidas por comunidades como Java, Ruby, Python e C# e essa é uma grande evolução em relação ao C++ (se eu um dia tiver de escrever alguma coisa em código nativo em algum futuro projeto Java, será uma boa idéia escrever em D).

Mas não chega a ser um Eldorado para a nova geração, como algumas pessoas podem pensar.

[]s

O modo interpretado é: O modo interpretado é interessante.

Pena que não tem herança múltipla. :-(

Por enquanto acho melhor eu continuar acompanhando o C++0x e estudado o boost.

--
Cesar Gimenes http://crg.eti.br
Linux user #76132

Herança múltipla: Sei não se é uma pena...

Até onde vai minha pouca experiência em C++ ("vc. é o doutor" aqui), herança múltipla é uma fonte de dores de cabeça de manutenção.

Fugir da herança múltipla (principalmente de ter que dar manutenção em códigos que a utilizam) foi uma das minhas motivações pra migrar pro Java.

Agora já mais dentro da minha especialidade (Java), eu percebi ao projetar sistemas que tudo o que vc. pode fazer com herança múltipla pode ser ajustado para funcionar sem ela. Talvez escrevendo um pouco mais (geralmente transformar uma das superclasses em interface, botar o código em uma outra classe concreta que implemente a interface, fazer com que a subclasse original implemente tb. a interface e delegar as chamadas à classe concreta), mas com um pouco mais de clareza e resistência a bugs.

herança múltipla?: Em tempos de python e ruby a adição de funcionalidade(implementada) se dá de forma horizontal e não vertical.
Que tal mixins?

Herança multipla só é: Herança multipla só é prob. se você usar de modo errado, o que se pode questionar é o fato de C++ dar a chance de você fazer algo "do modo errado".

No mais como você falou tudo o que se faz com herança multipla consegue-se fazer com interfaces, algumas vezes tendo que escrever um pouco mais....

Nem tanto...: ...Mixins seriam dinamismo demais pro meu gosto (é, eu não gosto de linguagens dinâmicas de script).

Uma simples substituição de herança por delegação já funciona para transformar crescimento vertical em horizontal.

É pena a falta da herança: É pena a falta da herança múltipla porque eu já tenho muito código bem projetado e escrito funcionando com esse recurso e não vou poder portar com simples ajustes para D. Falha minha de não ter explicado meus motivos para a palavra "pena".

Da para se virar sem herança múltipla, mas ela me ajuda muito a reutilizar código.

Quanto a ser uma fonte de dores de cabeça para manutenção, qualquer coisa em C++ se for mal usado é uma fonte de dores de cabeça. :-D

Outro dia um amigo disse uma frase legal se referindo sobre heranças múltiplas: "A diferença entre o remédio e o veneno esta na dosagem". Nem todo o código tem que ser estruturado assim mas em alguns lugares isso cai muito bem.

--
Cesar Gimenes http://crg.eti.br
Linux user #76132

"Modo errado"...: O problema é que, até onde foi minha experiência, qualquer uso de herança múltipla seria "o modo errado". Pode não parecer no princípio, mas vc. se arrisca a um problema posterior.

O que deveria acontecer na subclasse, conceitualmente, quando um método com o mesmo nome e lista de parâmetros existe em duas ou mais superclasses? Qual seria o método herdado?

C/C++ não é bom pra mim justamente porque é permissivo demais!

O mesmo problema com línguas ultra-dinâmicas de script, que permitem que vc. redefina radicalmente praticamente tudo em tempo de execução.

Eu gosto de um projeto onde dá pra ver claramente tudo o que está implementado (sem ter que consultar todo o "miolo" do código) e com zero de ambigüidade.

Ferramenta: Use uma ferramenta, ué...

Com uma ferramenta de refatoração, vc. pode fazer a conversão de herança múltipla para [herança simples + interfaces + delegação] de forma automática e praticamente sem riscos.

Existe uma ferramenta (escrita em java) chamada Jackpot que permite que permite definir nosssas próprias refatorações sobre código-fonte e depois executá-las.

Fazendo isso seu projeto ganha em clareza, sem perder muita coisa (não conheço seu projeto, é óbvio, mas pode-se dizer com perto de 100% de certeza que vc. terá benefícios).

mixins: Dei uma olhada na implementação de mixins do D.
Minha opinião é que é tão perigoso quanto herança múltipla, da para fazer uma bela macarronada de código com isso. :-D

--
Cesar Gimenes http://www.crg.eti.br
Linux user #76132

Mixin sucks! :-(: Pior: como eu poderia representar um mixin (qualquer implementação) em meu diagrama de classes (ou qualquer outro diagrama)?

:-<

Eu abomino essas coisas...

Erro de compilação:
O que deveria acontecer na subclasse, conceitualmente, quando um método com o mesmo nome e lista de parâmetros existe em duas ou mais superclasses?


Erro de compilação?! :-D


C/C++ não é bom pra mim justamente porque é permissivo demais!


Permissivo sim, pernicioso não :-D você pode usar apenas o que acha útil, claro, etc.

--
Cesar Gimenes http://crg.eti.br
Linux user #76132

É:

Erro de compilação?! :-D

Erro de design, antes de mais nada. Não deveria ser possível em tempo de projeto! Papel não compila diagramas.

Permissivo sim, pernicioso não :-D você pode usar apenas o que acha útil, claro, etc.

O problema é que vc. tem de manutenir código de outras pessoas... E, se um recurso efetivamente *existe* na linguagem, vc. não pode realmente dizer que elas estão erradas por usá-lo.

Erro de projeto.: A sim! Erro de projeto.

Lápis e papel aceita tudo :-)

--
Cesar Gimenes http://www.crg.eti.br
Linux user #76132

:-): Oras!

C++zeiros amam sua língua. E, como com qualquer amante, perdoam suas faltas e acabam arrumando um meio de conviver com elas, em paz.

Permitir, por sugestão da linguagem, a possibilidade que um erro de semântica seja propagado é bem ruim, na minha opinião. Dá pra consertar? Claro! Até hoje a gente só não conseguiu consertar a morte (se é que é necessário).

Herança múltipla já deveria ser proibida em UML! Só não é pq linguagens como C++ as permitem.

Delegação em Java é: Delegação em Java é fácil (pelo que li, não programo em Java) em C++ não temos esse recurso, temos apenas RTTI. (e ponteiros, muita gente não gosta, mas eu nunca tive problema com eles)
Também não temos interfaces, mas temos classes abstratas. :-D

De qualquer forma estou bem satisfeito com a implementação atual, apesar que em algumas partes eu ainda tenho alguns vícios do velho C. Eu gosto de ficar de olho em linguagens interessantes como D, Python, etc. mas como um hobby, não pretendo sair do C++ em um futuro próximo.

--
Cesar Gimenes http://www.crg.eti.br
Linux user #76132

:-( tem razão...: Como em C++ não há como implementar uma classe abstrata com a *garantia* de que todos os métodos serão também abstratos (o que em Java chamamos de Interface), não dá pra fazer o jogo de [herança simples + herança múltipla de Interfaces] que temos em Java.

É um exemplo de uma restrição que é, na verdade, uma feature!

O que talvez possa ser feito em C++ é usar o recurso de pré-compilador (ou pré-processador? Não lembro) para garantir que uma determinada classe abstrata que vc. escreva só tenha métodos abstratos (transformando-a dessa forma em uma "interface"). Daí vc. poderia fazer herança múltipla (envolvendo uma superclasse "real" e uma superclasse abstrata "restrita") com delegação de forma segura.

Vc. poderia talvez definir até um operador especial para expressar esse tipo de classe (abstrata, mas restrita). Ou não?

C++zeiros: Eu acho que nós, os C++zeiros somos até que bem ponderados. Nunca saiu um framewar na lista de C/C++ que participo e olha que já chegamos a discutir coisas como Linux X Windows. :-D

Existem problemas, mas eu convivo sem dores de cabeça com eles. Quando tenho um problema com um tipo de implementação eu simplesmente uso outra. :-D por exemplo eu não uso a dupla try/catch e desabilito esse recurso na linha de comando do gcc, simplesmente eu acho try/catch uma “técnica POG” e prefiro fazer da forma C, testando se um recurso existe e se esta disponível antes de tentar usar.
Herança múltipla eu não acho um recurso ruim, é uma questão de usar corretamente.

Outra coisa que não entendo é o tal coletor de lixo, vejo muitos programadores dizendo que isso é muito útil, necessário até, mas eu nunca tive problemas usando a dupla new/delete

Sim! É verdade que eu adoro C/C++, mas acredito que um bom programador deve mesmo amar sua linguagem favorita. Pela minha experiência posso dizer que não existe isso de projeto pequeno e que seja lá o que ele estiver escrevendo ele provavelmente vai ter que fazer isso durante muitos anos, é melhor ele gostar da linguagem ou vai esta com sérios problemas... palavra de quem tem mais de 20.000 linhas de código em VBA em que eu de vez em quando ainda tenho que dar manutenção, mesmo hoje, uma década depois. :-(

--
Cesar Gimenes http://crg.eti.br
Linux user #76132

vc. também?: Vc. também já foi "servo do mal"? rs. Eu também programei principalmente em VBA depois da faculdade, mas graças a Deus não preciso mais fazer manutenção daquilo. Os computadores que rodavam esses programas em meus antigos clientes já estão mortos e enterrados e os sistemas junto.

Em relação a técnicas, eu posso até achar questão de gosto mas penso que precisamos nos preocupar com quem lerá e fará manutenção em nosso código. Principalmente quando atuamos com FOSS (aos que detestam esse termo que me arrangem outra sigla pra descrever essa separação ridícula livre-open).

Por exemplo: eu discordo de você em relação ao try/catch. Ele permite deixar seu código menos verboso e evita o uso excessivo de operações condicionais (que na verdade funcionam como apenas asserções). É digno de pena o programador que lê uma função de 100 linhas na qual mais de 40 são condicionais checando por recuros indisponíveis, argumentos inválidos, etc.!

Outro exemplo é o coletor de lixo. Eu nunca conheci um programador C++ que diga que tem problemas com new e delete. A pergunta é: como é que vc. testa isso? Um memory leak pode se esconder de vc. por muito tempo e, na máquina/SO que vc. costuma rodar o programa, até calhar de nunca causar um problema (se vc. testou o suficiente). Mas em algum lugar, alguém vai recompilar teu código para outra plataforma (talvez com menos memória, ou mapeada de forma diferente) e aí de repente BUM!

Ou seja: se vc. testa seu sistema direito, talvez nunca tenha problema com alocação manual. Mas é possível que o usuário do teu código (que muitas vezes em código aberto vc. nunca vai conhecer) é que pode sofrer com ela.

Coletor de lixo reduz muito o risco de memory leaks. Mesmo assim, ainda pode acontecer mas é preciso grande falta de atenção, mesmo.

Sim, eu também adoro minha linguagem/plataforma e ainda gosto de C++.

Na verdade, minha única crítica a esta última é ter parado no tempo enquanto sua filosofia bota toda a culpa de maus projetos e sistemas com problemas em cima dos programadores.

P.S.: É claro que C++zeiros são os programadores mais "tranquilões" que existem. Seu nicho, mesmo que diminuído, não tem muitos desafiantes. :-D

Herança Multipla ? Sem problemas....: ....desde que vc saiba o que está fazendo. Ponteiros....sem problemas, desde que vc conheça e saiba o que está fazendo.

A abordagem Java de não utilizar herança multipla é boa e foi apregoada como uma das maiores características na Java World Tour que aconteceu aqui no Brasil em 1997, onde diversos "papas" da IBM, Sun, Oracle e Novell palestraram em nossas terras e me lembro bem que vários conceitos de C++ eram vendidos como "errados" e como ruins, inclusive um esquema confuso de Templates "que mais dificulta que ajuda" e agora muitas linguagens aparecem com o mesmo conceito, como a própria Java com o seu Generics.

Existe até discussão para que Java suporte pre-processadores (para facilitar na hora de manter uma única base de código entre versões J2ME e J2SE por exemplo) e pelo que li em foruns da Sun, até a famigerada Herança Multipla pode ser rediscutida.

Sobre sua pergunta ....

"O que deveria acontecer na subclasse, conceitualmente, quando um método com o mesmo nome e lista de parâmetros existe em duas ou mais superclasses? Qual seria o método herdado?"

....lhe faço outra:

O que deveria acontecer na classe, conceitualmente, quando um método com uma mesma assinatura existe em duas ou mais interfaces que vc está implemetando ? Como especificar para o método que quero chamar o método da relativo a interface A e não a da B ?

No caso de uma implementação de interface relativa a um evento , essa mesma "flaw" iria ocorrer se fosse feito com herança multipla, mas existe solução, basta pensar um pouco e projetar direito. Erro das linguagens ou do projetista ???????

Não existe nada de errado com C++ e sua herança multipla e seus ponteiros e seus templates e seus pré-processadores, o que existe é a mentalidade que empresas como a M$ implantou em nossas cabeças de que tudo que é estupidamente simples e sem requerer o mínimo de conhecimento e experiencia anterior é melhor....é nessas horas que muitos são abocanhados por armadilhas como VB.

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

Problema é não buscar solução:

"eram vendidos como "errados" e como ruins"

Ora, bolas! A motivação para a mudança é a insatisfação, certo? Se houvesse satisfação com o que C++ oferece, possivelmente Java seria até hoje como começou: um conjunto de macros para C++.

"como a própria Java com o seu Generics."

Se vc. estudar bem Generics e os Templates do C++, vai perceber que os recursos não são realmente iguais. Principalmente pq Java tem requesitos diferentes para Generics, o que motiva o uso de certas técnicas como o "apagamento" (erasure), que garante compatibilidade com código não-genérico.

Templates, tal como são implementados em C++ *não atendem à Java*. Por isso as propostas para a implementação (que começaram ainda pelos idos de 1999, se não me engano), ficou "congelada" até que aparecesse uma proposta aceitável, anos depois.

"Existe até discussão para que Java suporte pre-processadores (para facilitar na hora de manter uma única base de código entre versões J2ME e J2SE por exemplo)"

Péssimo recurso, na opinião da maioria da comunidade. Isso pq vc. não tem no na sua base de código a visibilidade do código que vc. terá após a compilação. O mesmo problema acontece com o AspectJ, que nunca se tornou um padrão.

Na comunidade Java se discute muita coisa (porque pensar e sugerir não é pecado e não fazê-lo é cegueira), mas poucas coisas realmente serão efetivamente parte da plataforma.

Tem gente discutindo tipagem dinâmica, herança múltipla, inclusão de XML na sintaxe, etc. Mas estas coisas não serão incluídas justamente pq essas discussões nos lembram os motivos pelos quais elas não existem. Por outro lado, é no meio dessas discussões que aparecem boas melhorias.

Aliás, lembrando de aspectos, Java hoje tem seu "pré-processador" sim. É o suporte para anotações (antes era praxe usar outros recursos, como - argh! - XML declarativo ou interfaces "marcadoras" - também não ideal). A *grande* diferença é que anotações definem informações secundárias, que não mudam o *comportamento* do seu código, mas sim como ele poderá ser usado.

Ex.: Uma classe marcada com uma anotação @Stateless será tratada como um objeto distribuído sem estado quando usada em um Servidor de Aplicações JEE. Mas uma aplicação desktop comum pode ignorar tranquilamente a anotação e a classe vai trabalhar do mesmo jeito.

"....lhe faço outra:

O que deveria acontecer na classe, conceitualmente, quando um método com uma mesma assinatura existe em duas ou mais interfaces que vc está implemetando ? Como especificar para o método que quero chamar o método da relativo a interface A e não a da B ?"

Excelente pergunta! :-D

A resposta é: NADA ACONTECERÁ DE ERRADO. VC.NÃO PRECISA ESPECIFICAR QUAL DOS DOIS, ELES SÃO, REALMENTE, IGUAIS! As interfaces não tem código executante, afinal (o que poderia gerar dúvidas quanto a qual implementação a ser usada) e fornecem a *garantia* de que nunca terão.

Isso faz com que "implementar" (é o termo que usamos para "estender de uma interface") duas interfaces com o mesmo método não seja um erro de projeto.

Se uma interface A estabelece que tem o método xpto() e uma interface B tem o mesmo método, isso só diz que a classe concreta C, que "implementa" ambas precisa definir obrigatóriamente o método xpto(). Nenhum problema aqui.

Ao contrário da herança múltipla de superclasses com funções concretas.

"o que existe é a mentalidade que empresas como a M$ implantou em nossa cabeça de que tudo que é estupidamente simples e sem requerer o mínimo de conhecimento e experiencia anterior é melhor..."

Está apontando no alvo errado. Se vc. usa facilidades que o ajudam a programar sem erros comuns e com a clareza necessária (que é o objetivo das línguas de alto nível, afinal), isso não significa que seu trabalho seja estupidamente simples (como arrastar componentes), nem que não exija conhecimento ou experiência. E a M$ não tem nada a ver com isso.

Costumo fugir do que a gente chama de "trabalho de corno", pq esse tipo de atividade não exige conhecimento ou experiência. Demanda só trabalho mecânico extra. E existem formas melhores de empregar meu tempo do que resolver problemas já solucionados competentemente antes.

"Não existe nada de errado com C++ e sua herança multipla e seus ponteiros e seus templates e seus pré-processadores"

Sim, para muita gente não há.

Mas eu digo que herança múltipla atrapalha meu design, que não preciso de ponteiros a menos que queira fazer coisas inseguras com eles, que templates C++ definem uma keyword extra sem necessidade e com risco de incompatibilidade com código que não os utiliza, e que pré-processadores escondem de mim o código que eu realmente vou ter rodando.

Templates, Generics, Interface, Java, C++ e etc !: "Se vc. estudar bem Generics e os Templates do C++, vai perceber que os recursos não são realmente iguais."

Sim, conheço ambos de grande experiencia com os mesmos e sua função é exatamente a mesma nas duas linguagens, considerando a devida diferença entre as linguagens.

Basicamente, o que um Template ? Não seria uma metodologia capaz de trabalhar com objetos dos mais variados de maneira abstrata e Genérica ?

Genérica..ops....não seria esse o conceito de Generics ?

Sobre o Erasure (ou Pet Shop Boys #.D ), essa técnica é util apenas para o desenvolvedor não precisar reaprender novas classes e perder sua experiencia nas Collections existentes, mas se vc utilizar da forma anterior, estará usando algo inseguro e que vc não sabe exatamente o que é.....igual a um ponteiro em C/C++.

"A resposta é: NADA! As interfaces não tem código executante, afinal (o que poderia gerar dúvidas quanto a qual implementação a ser usada) e fornecem a *garantia* de que nunca terão.
....
Se uma interface A estabelece que tem o método xpto() e uma interface B tem o mesmo método, isso só diz que a classe concreta C, que "implementa" ambas precisa definir obrigatóriamente o método xpto(). Nenhum problema aqui."

Sobre sua resposta, talvez eu não tenha sido mais claro na pergunta.

Vou utilizar um exemplo que é amplamente difundido através do Framework de Java principalmente na Swing.

Digamos que eu tenha um metodo A() implementado em minha classe B para duas interfaces diferentes (inclusive com propósitos diferentes) e um objeto dessa classe B é adicionado a um gerenciador de eventos, da primeira interface, que deverá chamar o método A() toda vez que o sistema receber um email e o mesmo objeto é adicionado a um outro gerenciador de eventos, da segunda interface, que deverá chamar o método A() sempre que o usuário digitar a tecla Z.

Ué ? Porque meu evento de recepção de email está disparando quando digito Z ?? Ou porque meu evento de checagem da tecla Z está disparando quando eu recebo um email ? Percebeu como sem herança multipla um "flaw" aconteceu aqui ?

Acabei de ter um problema similar a esse descrito acima no plugin ICQ/AIM do projeto PlanetaMessenger.org e te digo.....é possível e passa despercebido, ainda mais quando se implementa diversas interfaces e com códigos bem extensos e complexos.

Isso é bem comum de acontecer em linguagens que permitem implementação multipla de interfaces. Mas vamos abolir a implementação multipla de interface, assim como Java fez com a Herança multipla ?? Não creio que seja a melhor solução.

"E a M$ não tem nada a ver com isso."

Vc já conversou com o pessoal da M$ ??? Seus vendedores e evangelistas ???

Converse e verás que tem a ver sim, principalmente aqui no Brasil.

"...que templates C++ tornam meu código confuso e com risco de incompatibilidade com código que não os utiliza, e que pré-processadores escondem de mim o código que eu realmente vou ter rodando."

Quanto aos templates, se vc for desenvolvedor Java, deve ter o mesmo problema com Generics, sobre os pre-processadores, eles não escondem o código que vc terá rodando, eles simplesmente os remove do objeto binário final......e não seria esse o motivo de sua existência ?

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

servo do mal: VBA foi um capitulo triste na minha vida, ainda bem que acabou, o ultimo sistema (esse que tem 20.000 linhas) esta acabando de sem migrado para C++ e com interface web. O pior é que eu a adotei por besteira, eu já programava em C na época mas fui seduzido pelo lado negro... minha primeira linguagem foi o BASIC in ROM do Tk85 :-D

Quanto ao try/catch eu realmente não gosto, para mim tem cara de gambiarra, concordo que diminui o código, é verdade, mas acho que se separar as rotinas que fazem aquisição de recursos e se esforçar para escrever rotinas pequenas e bem documentadas resolve o problema da leitura do código.

Para detectar memory leak eu costumo usar duas abordagens, uma esta no meu estilo de programar, eu me empenho em fazer classes pequenas e a classe deve liberar qualquer recurso que adquiriu, na destrutora da classe eu checo se existem recursos alocados e se sim os libero. Também uso o valgrid e outras ferramentas, tanto para fazer otimização via profiling quanto para detectar memory leak.

De qualquer forma parece que quando sair a próxima versão do C++ teremos um coletor de lixo, pelo menos ele esta previsto no C++0x junto com outras coisas interessantes. Dei uma olhada e vi que já existem muitas implementações de coletor de lixo para C++, mas como eu falei ainda não vi uma necessidade nisso.

Também concordo que C++ deveria ter evoluído mais, algumas coisas que estão sendo propostas poderiam constar do padrão a mais tempo.

May the Source Be With You.

--
Cesar Gimenes http://www.crg.eti.br
Linux user #76132

C/C++ não necessita de evolução.....: ...pois na verdade ela é a evolução para sistemas operacionais e outras linguagens que são fundamentadas em C ou C++.

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

Agora já mais dentro da:

Agora já mais dentro da minha especialidade (Java), eu percebi ao projetar sistemas que tudo o que vc. pode fazer com herança múltipla pode ser ajustado para funcionar sem ela. Talvez escrevendo um pouco mais (...)

Assim como...

"Tudo projetado na Programação Orientada a Objetos pode ser feito sob o paradigma imperativo. [Talvez escrevendo um pouco mais]" --fãs da linguagem C.

Tenho que concordar.: Tenho que concordar. :-D

--
Cesar Gimenes http://crg.eti.br
Linux user #76132

100% pure C: Eu ainda escrevo muita coisa em C puro. É, da para fazer tudo com C puro... com um pouco mais de código. :-D

Quanto ao Java, a ultima vez que eu testei foi no fim de 1998 se não estou enganado, e ele simplesmente ainda não estava pronto. Muita coisa deve ter mudado de lá para cá, outro fator que me fez não investir em Java é que quando eu estava adotando C++ como minha "linguagem oficial" existiam oito empresas grandes fazendo compiladores C/C++, e existia a implementação livre também, já o Java tinha apenas uma empresa e uma implementação.

Agora com a história do Java virar software livre fiquei com vontade de dar uma nova olhada nele, com certeza deve ter melhorado muito desde minha ultima olhada. :-D

Mais assim como D, Java seria só uma curiosidade em um primeiro momento, o motivo é mais humano que técnico, depois que se alcança um certo grau de eficiência/experiência em uma determinada linguagem é complicado mudar, você já conhece todos os buracos do caminho, conhece a sintaxe, e claro tem muito código legado. É aquele estagio em que as coisas simplesmente funcionam e você começa a achar que é fácil quando na verdade é você que esta ficando bom nisso.
É por esse motivo que amigos que escrevem programas em C++ na verdade escrevem programas em "C com classes" :-D, simplesmente o cara sabe tudo de C e as coisas funcionam.


Estou gostando de ver, esse papo não descambou para um framewar, a comunidade esta amadurecendo?

--
Cesar Gimenes http://crg.eti.br
Linux user #76132

O problema é que delegar: O problema é que delegar via associação (composição no caso) gera acoplamento. Entre composição e herança eu tbm ficaria com composição.

Os mixins são: Os mixins são executados/gerados por mensagens, mixer.mix(ClassA,ClassB). No final das contas, como você vai representar isto depende de como você usa uml.

Eu não vi D (ainda), mas: Eu não vi D (ainda), mas convenhamos dá pra fazer porcaria com qualquer linguagem, não?