Na minha opinião, nem todos os forks tem motivos técnicos ou egocentricos. Existem pessoas que gostam de desafios e/ou de estudar... Eu mesmo de vez em quando me pergunto: "se eu fosse fazer [ponha aqui qq coisa complicada, sem solução instantanea, q já existe no CPAN], como eu faria?!". Eu não quero reinventar a roda, mostrar q o meu é melhor! sou movido pela pura curiosidade cientifica! Quero saber como EU faria! Quero passar por problemas q nunca passei. e tendo feito isso, estando pronto, porque não botar no CPAN?! Tudo bem, ele faz exatamente a mesma coisa q faz o [ponha aqui qq coisa complicada, sem solução instantanea, q já existe no CPAN] mas não é a mesma coisa! Isso q eu fiz pode ajudar outras pessoas... pq não botar no CPAN?!<br>
<br><div class="gmail_quote">2008/5/19 Marco A P D'Andrade <<a href="mailto:mdacwb@gmail.com">mdacwb@gmail.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A mentalidade da comunidade, ao meu ver, tem mudado, veja que hoje<br>
temos até literatura formal defendendo as melhores praticas (Best<br>
Practicals)...<br>
<br>
Eu li um artigo, que é claro, não lembro onde foi, de um defensor de<br>
Ruby, que elogiava CGI::Application, Catalyst e Maypole, e se<br>
vangloriava do fato de ter apenas o Rails para aprender, e conviver<br>
com os problemas (que segundo ele não são poucos)...<br>
<br>
Fork por questões técnicas, restrições de licença, ótimo... mas fork<br>
por mero ego politico... acho pésssimo !<br>
<br>
Eu tenho o hábito de produzir código que outro dará manutenção, ou ao<br>
menos perseguir isto. Entendo que para módulos que serão continuados<br>
por muito tempo, é de grande importância pensar em incorporar as<br>
praticas de modelagem, já adotadas a muito tempo no cpan (com no<br>
mínimo de documentação, testes, namespace, etc).<br>
<br>
Confesso que não adotei todas as praticas ainda, mas reconheço esta<br>
pendencia, e estou tentando corrigir, de forma que meus proprios<br>
módulos e sistemas internos sejam instalados na base do "perl<br>
Makefile.PL" ...<br>
<br>
até porque... é muito mais simples assim ;)<br>
<br>
<br>
Sds,<br>
Marco Antonio<br>
<br>
<br>
2008/5/19 breno <<a href="mailto:breno@rio.pm.org">breno@rio.pm.org</a>>:<br>
<div><div></div><div class="Wj3C7c">> Opa, peraí! Deixa eu defender meu argumento, ele é um pouco mais<br>
> complexo que isso... (xiii, lá vem os emails enormes do breno :-P)<br>
><br>
> Não sou contra diversidade. TIMTOWTDI é uma das mais interessantes e<br>
> únicas características do Perl. O que me incomoda é que sinto haver<br>
> muita individualidade na comunidade Perl, que aproveita essa<br>
> característica e parece (meu ponto de vista) trocar de módulo como<br>
> quem troca de roupa, sem oferecer um mínimo de continuidade, suporte<br>
> ou evolução ao que apresenta aos desenvolvedores.<br>
><br>
> Claro que há excessões, mas um exemplo típico é o Sebastian Reidel,<br>
> que começou no Maypole e, por não gostar da direção que o projeto<br>
> estava tomando, criou o Catalyst, e agora parece estar abandonando o<br>
> Catalyst para fazer um novo (?!) framework. Posso estar redondamente<br>
> enganado, mas a sensação que isso passa (pelo menos para mim) é de<br>
> fuga. E vejo isso constantemente no CPAN: um módulo X faz A,B e C mas<br>
> eu preciso de D então, ao invés de colaborar com o projeto original<br>
> deixando ele robusto e até personalizável através de subclassing ou<br>
> contribuições diretas, eu vou lá e faço um outro do zero, que faz A,<br>
> B, C e D. Aí outra pessoa quer A, B e Z, então ela escreve outra coisa<br>
> completamente diferente também. O resultado disso é um monte de<br>
> implementações diferentes de A e B com praticamente a mesma estrutura<br>
> e API, mas em estágios de maturidade completamente desconhecidos, sem<br>
> um "core" comum.<br>
><br>
> Eu mesmo vi na documentação da API de plugins do Catalyst que ele pede<br>
> "POR FAVOR" para as pessoas não criarem plugins que fazem o que outros<br>
> módulos já implementam (e muito bem, diga-se de passagem), "estamos<br>
> falando de Perl! Vcs podem simplesmente usar o módulo - ele não<br>
> precisa ser um plugin ou estar no namespace do Catalyst para fazer<br>
> parte de sua aplicação ou interagir com o framework". E EMHO eles<br>
> estão certíssimos.<br>
><br>
> Como disse, o que sinto falta é na colaboratividade (essa palavra<br>
> existe?) entre desenvolvedores, é pegar um módulo que faz quase o que<br>
> vc quer e melhorá-lo, extendê-lo, criar subcomponentes, enfim, e não<br>
> fazer um fork dele. Para não ficarmos em A,B e C vejamos um exemplo<br>
> claro disso: o Net::SMTP. Quem não conhece o Net::SMTP? É um ótimo<br>
> módulo para envio de email. Mas o Net::SMTP só faz autenticação por<br>
> SASL. E se vc quiser autenticar por TLS (como o gmail)? Ah, uma alma<br>
> caridosa fez o Net::SMTP::TLS, que suporta autenticação por TLS e<br>
> AUTH. Só que, apesar de estar no mesmo namespace, ter praticamente a<br>
> mesma API e constantemente ao longo da documentação apontar para o<br>
> Net::SMTP, ele não é uma subclasse de fato, e implementa tudo do<br>
> zero!!! Resultado: pequenas nuâncias de sintaxe te obrigam a fazer<br>
> malabarismo se quiser que sua aplicação suporte ambas as formas de<br>
> autenticação, quando uma boa subclasse deixaria o processo<br>
> completamente transparente (ou, se não fosse realmente possível, ele<br>
> poderia implementar diretamente no Net::SMTP). Fora que atualizações<br>
> de implementação do Net::SMTP não se propagam para o N::S::TLS. Vcs me<br>
> desculpem, mas eu não acho isso absolutamente interessante.<br>
><br>
> Uma coisa é não gostar de uma API para fazer X e desenhar sua própria,<br>
> que é o princípio do TIMTOWTDI e de alguns frameworks diferentes.<br>
> Outra é reescrever a roda a cada turno, só pq algo não faz exatamente<br>
> o que vc quer. O que houve com o RT?! O que houve com o<br>
> cvs/svn/git/etc?! O que houve com a colaboração entre<br>
> desenvolvedores?! Com subclassing?! Essa é a minha constante crítica.<br>
> Algo não faz o que vc quer, ou não faz direito? Vai lá e conserta!<br>
> Aponta o problema! Sugira! Participe! E não sente e faça seu próprio<br>
> de novo do zero. Não vejo sentido nisso, a não ser auto-aprendizado ou<br>
> auto-martírio.<br>
><br>
> Dar diversidade ao desenvolvedor é ótimo. Mas ele tem que, no mínimo,<br>
> ser orientado quanto a quais as características de cada opção para<br>
> escolher a melhor para si. E se o módulo não fizer tudo que ele quer,<br>
> ele deve ser estimulado a colaborar com o projeto, e não criar (mais<br>
> um) fork.<br>
><br>
> Acredito piamente que se os desenvolvedores Perl tivessem essa<br>
> mentalidade de extensão e colaboração ("não faz tudo que vc quer?<br>
> colabore, extenda e seja feliz!") em vez de o que me parece vigente<br>
> hoje ("não faz tudo que vc quer? faz o seu próprio e seja feliz!"),<br>
> ainda teríamos 2/3 do CPAN, todas as vantagens do Perl e do TIMTOWDTI<br>
> e ao mesmo tempo muito mais estabilidade, escalabilidade, evolução,<br>
> estrutura e orientação no desenvolvimento de aplicações, sem que o<br>
> desenvolvedor se perca no mar de 15000+ distribuições.<br>
><br>
> Isso, e um mapa de desenvolvimento de aplicações no CPAN, seria ótimo<br>
> (hmmm...idéias....acho que já sei do que vou falar no próximo YAPC::SA<br>
> :-)<br>
><br>
><br>
> []s<br>
><br>
> -b<br>
><br>
><br>
> On Mon, May 19, 2008 at 12:50 AM, Eden Cardim <<a href="mailto:edencardim@gmail.com">edencardim@gmail.com</a>> wrote:<br>
>> On Mon, May 19, 2008 at 12:20 AM, Lorn <<a href="http://lorn.br" target="_blank">lorn.br</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>> wrote:<br>
>>> Ops, falha minha :) foi mal.<br>
>>> Mas continuo achando que ainda falta um "ponteiro" para essas coisas novas,<br>
>>> tipo ao acessar o manual do CGI.pm ter um apontamento para o Catalyst/Jifty<br>
>>> e afins.<br>
>><br>
>> Interagir com a comunidade é a melhor forma de ficar por dentro das novidades.<br>
>><br>
>> --<br>
>> <a href="http://edenc.vox.com" target="_blank">edenc.vox.com</a><br>
>> _______________________________________________<br>
>> SaoPaulo-pm mailing list<br>
>> <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>> <a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a><br>
>><br>
> _______________________________________________<br>
</div></div>> Cascavel-pm mailing list<br>
> <a href="mailto:Cascavel-pm@pm.org">Cascavel-pm@pm.org</a><br>
> <a href="http://mail.pm.org/mailman/listinfo/cascavel-pm" target="_blank">http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br>
><br>
_______________________________________________<br>
Cascavel-pm mailing list<br>
<a href="mailto:Cascavel-pm@pm.org">Cascavel-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/cascavel-pm" target="_blank">http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Just another Perl Hacker,<br>Fernando (SmokeMachine)<br><a href="http://perl-e.org">http://perl-e.org</a>