>>>>> "Frederico" == Frederico Recsky <[email protected]> writes: Frederico> Otimo, então eu tenho um core gordo que ainda precisa Frederico> de plugins para fazer coisas "avançadas". O minimo que Frederico> eu espero de um programador também é que ele entenda o Frederico> conceito de plugins e acoplar as coisas.
Nem é tão gordo assim, na real, se você rodar o Perl::Metrics::Simple no repositório de ambos, vai ver que de fato, o Mojo é mais gordo: http://pastie.org/8167416 http://pastie.org/8167419 O mojo além de ter quase o dobro de código, o código existente é mais complexo. Mas isso é porque ele oferece mais funcionalidades out-of-the-box. A questão que o Nelson está ressaltando é a natureza "caixa-preta" do Mojo e ele está correto nesse aspecto. É um pacote de funcionalidade consolidada que implica em não olhar ou conhecer os internals em momento algum. Isso é uma característica do autor do framework, que é um "lone wolf" e gosta de ter controle sobre o código. Pra esse tipo de desenvolvedor (e existem muitos), essa abordagem realmente faz mais sentido. O Catalyst segue a filosofia contrária, a da caixa-branca. É uma porção de módulos que foram se aglomerando em torno das 3 mil linhas do core original (o que está dentro do Catalyst.pm) criados e refinados por diversos autores que se preocupam em não pisar nos pés uns dos outros. Esse core é estruturado de forma a facilitar a escrita de módulos contribuídos/dependências e não a funcionalidade end-user. Você precisa combinar os módulos desse eco-sistema para obter o resultado desejado, coisa que prum iniciante isolado e mal-orientado é realmente mais difícil porque ele não tem conhecimento do eco-sistema. Porém, numa equipe cirúrgica ou ágil essa abordagem faz muito sentido. -- Eden Cardim -- Insolide Soluções de TI Ltda. +55 11 9644 8225 http://insoli.de =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
