[Rio-pm] hash como parametro

Gabriel Blum blum em pobox.com
Quinta Julho 1 07:21:52 PDT 2010


Pois é, mas o perl de alguma maneira emula que vc está trabalhando com uma
cópia. Provavelmente se vc tentar escrever no objeto passado por parametro
(mas secretamente referenciado), ele deve efetivamente copiar. Sei lá

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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20100701/1bcdfb7e/attachment.html>


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