Em 14 de junho de 2011 20:11, Thiago Rondon <[email protected]> escreveu:
> On Tue, Jun 14, 2011 at 07:40:36PM -0300, Andre Carneiro wrote: > > Por favor, nada de flames por bobagens como essa q eu escrevi... > > > > > > Andre, > > Olha, este papo de depedencia é bem complicado de argumentar, vou > colocar aqui minha visão sobre isto e um exemplo com o próprio > Mojolicious. > > Mas, o simples fato de ter depedencia não é um problema, e porque não > é um problema ? > > 1 - Você esperar um pouco mais para instalar não é um problema. Bom, sinto dizer q não é pouco... > 2 - Você só vai instalar uma vez, ou em algum deploy. > Pois é, se eu tiver um monte de clientes, é bom eu me planejar bem como vou distribuir esses deploys. Caso contrário posso morrer de tédio! E não, não consigo escrever coisa melhor! > 3 - Você esta adquirindo um conhecimento e materia prima desenvolvida. > Do que vc está falando? Eu só tö falando de instalar o Catalyst + plugins que eu preciso. Conhecimento do q?? 4 - Você esta na maioria dos casos como 'deploy' usufruindo de testes novos. > 5 - Maturidade, código utilizado e compartilhado por mais ambientes. > 6 - (...) > > Certo, certo... Bom, como eu disse, isso ME incomoda. Logo não era para incomodar VOCÊ. Não precisa me explicar nada. Eu sei perfeitamente que o Catalyst é muito bem escrito, e tem um cacetilhão de plug-ins e blablabla... > E quando pode ser um problema ter dependencias ? Na minha opinião, > apenas quando você esta utilizando um módulo mal escrito, > e para isto é importante que você saiba onde esta pisando, saber > da qualidade das dependencias é importante. > > Nunca falei q o Catalyst é mal escrito. Tão pouco que a qualidade das depências é ruim. Eu só... a, deixa vai... falaê! > Por isto criar componentes e abstrações pode ser uma boa saída para > que isto fique mais saúdavel, veja por que alguns módulos hoje são > mais utilizados, tais eles como o DBI que é uma camada para os bancos > de dados, o AnyEvent que é uma camada para os módulos de evento, o > Cache que é abstração para os módulos de cache. > > Dessa vez eu lembrei de guardar pra mim... :-p > Por exemplo, veja o exemplo do Cache: http://lmctfy.org/Cache/ > > Veja que existem vários módulos que seguem esta mesma interface, e > isto ajuda o ecosistema dos módulos de cache serem mais saúdavel e > funcionarem de forma orgânica. (edenc++ pela expressão). > > Não quero jogar pedras, mas apenas explicar por que o argumento > de dependencias e falta de componentes fazem falta em um framework > e por que na minha humilde opinião acredito que ele deva melhorar > com o desenvolvimento: > > > https://github.com/kraih/mojo/commits/507ece232a8975d1626263cc4d875f13148fa1e7/lib/Mojo/JSON.pm > > Existem módulos de JSON que são utilizados por muitos outros módulos, > frameworks e etc... já prontos e com uma perfomace muito aceitavel > (JSON::XS). > > Porém, por algum motivo (alguém sabe pq ?) o pessoal do Mojolicious > resolveu escrever o seu próprio, veja a quantidade de bugs que eles > estão arrumando ainda. (vide histórico) > > Vale apena re-inventar a roda neste caso ? Para você não ter mais uma > dependencia (para o JSON neste caso), existe um módulo novo sendo utilizado > e com bugs "já velhos" sendo consertado o tempo todo ? > > Agora fica minha pergunta, neste caso dependencias é bom ou ruim ? > > TIrando o fato de ser um excelente sonífero( o que menos importa de qualquer forma ), não vejo problemas. > Abs, > -Thiago Rondon > > -- André Garcia Carneiro Analista/Desenvolvedor Perl (11)82907780
=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
