[Rio-pm] hash como parametro

Fernando Oliveira fernandocorrea em gmail.com
Quinta Julho 1 07:36:17 PDT 2010


Solli,

Ah! Blz!!! Foi mau!

Just another Perl Hacker,
Fernando (SmokeMachine)
http://perl-e.org


2010/7/1 Solli Honorio <shonorio em gmail.com>

> Ok, este é o problema da nomenclatura. Quando eu disse objeto, não estava
> me referindo a uma classe instânciada, eu estava em mente um recurso de
> memória instanciada .... ou seja, um grande array ou um grande hash.
>
> 2010/7/1 Fernando Oliveira <fernandocorrea em gmail.com>
>
>> Eu não entendí... objs já são referencias...
>> Vc só passa objs por referencia mesmo...
>> Just another Perl Hacker,
>> Fernando (SmokeMachine)
>> http://perl-e.org
>>
>>
>> 2010/7/1 Andre Carneiro <andregarciacarneiro em gmail.com>
>>
>>>
>>>
>>> Achei que diria isso mesmo, obrigado!
>>>
>>>
>>> Cheers!
>>>
>>>
>>> 2010/7/1 Solli Honorio <shonorio em gmail.com>
>>>
>>>>
>>>> 2010/7/1 Andre Carneiro <andregarciacarneiro em gmail.com>
>>>>
>>>>
>>>>>
>>>>> 2010/7/1 Solli Honorio <shonorio em gmail.com>
>>>>>
>>>>>
>>>>>> Em 1 de julho de 2010 10:09, Solli Honorio <shonorio em gmail.com>escreveu:
>>>>>>
>>>>>>
>>>>>>> 2010/7/1 GmailPaqui <cpaqui em gmail.com>
>>>>>>>
>>>>>>>>  Caros, bom dia!
>>>>>>>>
>>>>>>>>
>>>>>>>> Se a passagem de parâmetros por referência é ruim, como proceder no
>>>>>>>> caso onde tenho dois parâmetros, um hash e um scalar, e o segundo parâmetro
>>>>>>>> é opcional?
>>>>>>>> Devo testar se hash está completo, pares de valor?
>>>>>>>>
>>>>>>>> --
>>>>>>>>  *Cleive Paqui*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Cleive,
>>>>>>>
>>>>>>> Como disse o Gabriel, não é ruim, só estamos extrapolando uma questão
>>>>>>> técnica. A passagem por referência é uma opção válida e está dentro (e muito
>>>>>>> utilizada) do estilo de programação Perl. O único cuidado que é preciso ter
>>>>>>> quando você passa o valor por referência é ter a consciência de que as
>>>>>>> alterações dos valores nestas referencias dentro da função resultará na
>>>>>>> alteração do valor fora da função.
>>>>>>>
>>>>>>> Dito isto, a tua pergunta permite a discussão da(s) boa(s) prática(s)
>>>>>>> para os parâmetros, e  eu achei que alguém iria abordar isto antes. Seguindo
>>>>>>> o PBP (Perl Best Practice - http://amzn.to/aDbCpR ) temos algumas
>>>>>>> recomendações sobre este assunto, sendo eles (não lembro de todos pois não
>>>>>>> estou com o PBP aqui agora) :
>>>>>>>
>>>>>>> * return - não misture interface de erro com interface de dados. Se
>>>>>>> você utilizar o return para erro, só utilize para isto. Se utilizar para
>>>>>>> retornar o resultado da função, utilize apenas para isto. NUNCA faça as duas
>>>>>>> coisas ao mesmo tempo (ou pelo mesmo canal);
>>>>>>>
>>>>>>> * parâmetros
>>>>>>> 1o. nunca manipule diretamente os valores através do $_[0], $_[1]
>>>>>>> ..., a menos que você realmente saiba o que está fazendo. E se você
>>>>>>> realmente souber, não fará isto numa programa sério. Além ter de alterar os
>>>>>>> valores originais, isto deixa o programa ilegível;
>>>>>>>
>>>>>>
>>>>> Traduzindo... assim que obter $_[0] , $_[1], ou mesmo $1, $2(oriundas
>>>>> de expressões regulares), trate de colocar numa variável declarada o mais
>>>>> rápido possível!
>>>>>
>>>>>
>>>>>>
>>>>>>> 2o. utilize a atribuição simples (sem passagem de referencia) apenas
>>>>>>> quando for utilizado até 2 parâmetros scalares ou apenas um parâmetro de
>>>>>>> grupo (hash ou array);
>>>>>>>
>>>>>>
>>>>> Eu já vi isso no PBP, mas acho discutível. No caso do meu trabalho,
>>>>> normalmente trabalho com alguns objetos relativamente grandes(estou falando
>>>>> de HTML::TreeBuilder::XPath). Nesse caso eu prefiro passar por referência
>>>>> para evitar a cópia desse objeto. Mas você tem razão ao dizer que tem que se
>>>>> tomar muito cuidado com o que se faz, depois que a função para qual se
>>>>> passou a referência termina, pois o objeto ainda estará ativo fora do escopo
>>>>> dessa função. Um exemplo que eu tenho sempre por aqui...
>>>>>
>>>>> <code>
>>>>>
>>>>> .
>>>>> .
>>>>> .
>>>>> my $tree = HTML::TreeBuilder::XPath->new_from_content($string);
>>>>> $self->treat_tree(\$tree);
>>>>> $tree = $tree->delete; # Isso aqui destroi o objeto !!!
>>>>>
>>>>> .
>>>>> .
>>>>> .
>>>>>
>>>>> sub treat_three {
>>>>>    my ($self, $tree) = @_;
>>>>>
>>>>>    my pedaco_de_html = ${$tree}->findnodes("/html//body/... ");
>>>>>
>>>>> .
>>>>> .
>>>>> .
>>>>>
>>>>> }
>>>>>
>>>>> </code>
>>>>>
>>>>>
>>>>> Solli, você acha esse tipo de coisa válida ou eu realmente deveria
>>>>> passar $tree sem a referência? Eu pessoalmente prefiro passar por referência
>>>>> como disse, para evitar a cópia do objeto, e também, para evitar que eu
>>>>> tivesse que destruir o objeto HTML::TreeBuilder::XPath duas vezes no
>>>>> caso(uma na função e outra fora dela). Por favor me dê sua opinião sobre
>>>>> esse caso.
>>>>>
>>>>
>>>> Eu recomendo passagem por referência mesmo, a minha preocupação aqui nem
>>>> é desempenho e sim consumo de recurso. Sabemos que as linguagens dinâmicas
>>>> não gostam de liberar memória após o uso, então quando estou lidando com
>>>> objetos pesados eu gosto de utilizar referências para evitar problema com
>>>> este recurso.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> 3o. é fortemente recomendado utilizar a técnica de "named arguments".
>>>>>>> Isto significa passar os argumentos através de uma hash, onde a tua função
>>>>>>> poderá saber se todos os argumentos obrigatórios estão presente.
>>>>>>>
>>>>>>> 4o. considere retornar o resultado de uma função via um argumento de
>>>>>>> referencia.
>>>>>>>
>>>>>>> Um exemplo, meu, para uma subrotina seria assim :
>>>>>>>
>>>>>>> <code>
>>>>>>>
>>>>>>> sub minha_rotina {
>>>>>>>   my %args = @_;
>>>>>>>
>>>>>>>   # verifica argumentos obrigatórios
>>>>>>>
>>>>>>>   for my $arg ( qw (arg1 arg3 arg4 ) ) {
>>>>>>>     die "Argumento $arg é obrigatório mas não foi informado" if !
>>>>>>> exist $args{$arg};
>>>>>>>   }
>>>>>>>
>>>>>>>   ... faça alguma coisa com os argumentos ...
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> </code>
>>>>>>>
>>>>>>> Outras fontes sobre isto :
>>>>>>>
>>>>>>> http://www.perl.com/pub/a/2006/02/23/advanced_subroutines.html
>>>>>>> (mas por favor, nunca utilize prototypes)
>>>>>>> http://perldesignpatterns.com/?NamedArguments
>>>>>>> http://www.devshed.com/c/a/Perl/Subroutines-in-Perl/3/
>>>>>>> http://www.cs.cf.ac.uk/Dave/PERL/node126.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Rio-pm mailing list
>>>>>>>> Rio-pm em pm.org
>>>>>>>> http://mail.pm.org/mailman/listinfo/rio-pm
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> "o animal satisfeito dorme". - Guimarães Rosa
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> "o animal satisfeito dorme". - Guimarães Rosa
>>>>>>
>>>>>> _______________________________________________
>>>>>> Rio-pm mailing list
>>>>>> Rio-pm em pm.org
>>>>>> http://mail.pm.org/mailman/listinfo/rio-pm
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> André Garcia Carneiro
>>>>> Analista/Desenvolvedor Perl
>>>>> (11)82907780
>>>>>
>>>>> _______________________________________________
>>>>> Rio-pm mailing list
>>>>> Rio-pm em pm.org
>>>>> http://mail.pm.org/mailman/listinfo/rio-pm
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> "o animal satisfeito dorme". - Guimarães Rosa
>>>>
>>>> _______________________________________________
>>>> Rio-pm mailing list
>>>> Rio-pm em pm.org
>>>> http://mail.pm.org/mailman/listinfo/rio-pm
>>>>
>>>
>>>
>>>
>>> --
>>> André Garcia Carneiro
>>> Analista/Desenvolvedor Perl
>>> (11)82907780
>>>
>>> _______________________________________________
>>> Rio-pm mailing list
>>> Rio-pm em pm.org
>>> http://mail.pm.org/mailman/listinfo/rio-pm
>>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>
>
>
> --
> "o animal satisfeito dorme". - Guimarães Rosa
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20100701/ebc69101/attachment.html>


Mais detalhes sobre a lista de discussão Rio-pm