Na oscon 2011 teve uma palestra do Piers Cawley sobre dynamic dispatch que
nada mais era do que uma forma de vc evitar eval /try-catch pois eles são
bem custosos em Perl. Basicamente vc fazia um chain desse tipo
try {
objeto->metodoA->metodoB->metodoC();
} catch {
objeto->metodoD
}
Isto poderia ser algo assim
objeto->metodoA->metodoB->metodoZ();
e o metodo B sabendo que ocorreu um erro ao inves de fazer um die/throw/etc
simplesmente retornava um objeto cujo metodoZ é o "tratamento" do mesmo.
Algo como
$controller->init()->process()->show()->clean();
o show normalmente vai mostrar o resultado de process. Mas pode ser que o
resultado "anormal" tambem possa ser mostrado (como em uma pagina de erro).
E eu posso querer limpar algo em caso de falha -- assim o show poderia
retornar um objeto falso cujo clean não faz nada em caso de sucesso.
Enfim, cada abordagem tem vantagens e desvantagens.
2012/6/21 Solli Honorio <[email protected]>
> <ironic_mode>
>
> Caramba Marcio,
>
> Sério mesmo que um dos motivos pelo qual um CIO escolhe Java ou .Net é pq
> tem um sistema de Exception que possui try{...}catch{...} ? O fato de ter
> uma empresa mainstream na parada não é importante ? Se for assim, como foi
> que o VB, o Clipper, o Fortran foi (e ainda é) escolhido pelas empresas ?
>
> Abraços,
>
> Solli Honorio
>
> </ironic_mode>
>
> Em 21 de junho de 2012 16:55, Marcio Ferreira <
> [email protected]> escreveu:
>
> Esse é um dos motivos de Java, .Net dominar tanto mercado
>>
>> []s,
>>
>> Marcio Ferreira
>> @_marcioferreira
>> (11) 8567-1482 skype: marcio.ferreir4
>> marciodesouzaferreira.blogspot.com
>>
>>
>>
>> 2012/6/21 Daniel Mantovani <[email protected]>
>>
>>> Para tudo, se você deseja verificar os argumentos que seus métodos vão
>>> receber e também com performance não use uma linguagem dinâmica.
>>>
>>> "Programs written in dynamically typed languages require large suites of
>>> tests to give some assurance that simple type errors cannot occur. Test
>>> suites cannot offer complete coverage: some common tasks, such as
>>> refactoring a program to make it more modular, can introduce new type
>>> errors that a test suite may not expose."
>>>
>>> Eu usaria Haskell, por nativo proporciona que todas funções sejam
>>> avaliadas em compile time, eu odeio escrever testes. Por exemplo, toda
>>> expressão em Haskell tem um tipo declarado.
>>>
>>> Prelude> :type odd
>>> odd :: Integral a => a -> Bool
>>>
>>> A função "odd" recebe um único valor inteiro e retorna um valor booleano.
>>>
>>>
>>> --
>>> Software Engineer
>>> Just Another Perl Hacker
>>> Daniel Mantovani +5511 8538-9897
>>> XOXO
>>>
>>> On Jun 21, 2012, at 3:40 PM, Thiago Yukio Kikuchi Oliveira wrote:
>>>
>>> > 2012/6/21 Solli Honorio <[email protected]>:
>>> >> Ok, mas aparentemente a penalidade de desempenho não vale a pena
>>> ainda...
>>> >>
>>> >> Solli Honorio
>>> >
>>> > Não utilize do MooseX::Method::Signature, ele é muito lento.
>>> > Utilize o Method::Signatures pois é muito mais rápido.
>>> > Olhe a comparação dos dois:
>>> >
>>> http://www.dancygier.com/wordpress/2011/03/06/methodsignatures-blazing-fast-and-makes-me-sane/
>>> >
>>> > Existe o módulo Method::Signatures::Modifiers que permite utilizar o
>>> > MooseX::Declare com o Method::Signatures
>>> > ao invés do MooseX::Method::Signature.
>>> >
>>> >
>>> > Thiago
>>> > =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
>>>
>>> =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
>>>
>>
>>
>> =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
>>
>>
>
>
> --
> "o animal satisfeito dorme". - Guimarães Rosa
>
> =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
>
>
--
Tiago B. Peczenyj
Linux User #405772
http://pacman.blog.br
=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
