[Rio-pm] Chaves de hash

Tiago Peczenyj tiago.peczenyj em gmail.com
Quinta Novembro 29 16:41:58 PST 2012


veja este exemplo:

https://gist.github.com/4172935

veja como a execução das subrotinas não é alterada, mas o resultado das
variaveis é diferente.

my $x = a and b and c and ok or nok;

my $y = a && b && c && ok || nok;

veja que x recebe o valor que a retorna, enquanto y recebe o valor de nok.

isso pq o = esta em termos de precedencia entre o and e o &&



2012/11/29 Bruno Buss <bruno.buss em gmail.com>

>
>
> 2012/11/29 Bruno Buss <bruno.buss em gmail.com>
>
>> On Thu, Nov 29, 2012 at 10:13 PM, Renato Santos <renato.cron em gmail.com>wrote:
>>
>>> use && sempre e seja feliz, só use and quando você souber oque está
>>> fazendo.
>>>
>>
>> Desculpe mas vou discordar que um bom conselho seja "use && sempre e seja
>> feliz", ainda mais seguido de "só use and quando você souber oque está
>> fazendo". Na melhor da hipóteses são sugestões contraditórias... como
>> alguém deverá saber quando usar o 'and' se apenas usa o && cegamente?
>>
>>
>>> o 'and' é praticamente o 'e' da nossa lingua, vc diz pro seu codigo
>>> 'faça isso, e isso', ele não é de comparação, embora faça
>>>
>>
>> "ele não é de comparação, embora faça"? Poderia desenvolver melhor, pois
>> não fui incapaz de entender o que isso significa para um operador lógico
>> (que a única diferença do outro é a baixa precedência).
>>
>
> s/incapaz/capaz/;
>
>
>>
>>
>> E vou repetir a pergunta aqui, antes que ela fique soterrada pelas tricks
>> de sleep: Qual diferença isso faz no caso deste if específico do Aureliano?
>> Por que exatamente, no if dele, utilizar o 'and' está incorreto? Porque no
>> if dele, somente o && "dá certo" como 3 pessoas já disseram?
>>
>>
>> --
>> Bruno C. Buss
>> http://www.brunobuss.net
>>
>
>
>
> --
> Bruno C. Buss
> http://www.brunobuss.net
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>



-- 
Tiago B. Peczenyj
Linux User #405772

http://pacman.blog.br
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20121129/24d7f56f/attachment.html>


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