[Rio-pm] Chaves de hash

Aureliano Guedes guedes_1000 em hotmail.com
Sexta Novembro 30 02:51:04 PST 2012


Sua ideia é louvável, mas há um problema.

No Arquivo que eu postei, eu "compilei" de a rotina de um modulo dentro do script.
Isso se deve ao fato de eu ter desenvolvido um modulo que parseia todo o documento naquele formato
e cria um hash colocando como chave o valor que eu procuro, que pode ser o nome do micro-RNA, a energia de ligação,
a posição no gene, ...
Criei esse modulo (que futuramente pretendo adicionar no CPAN ou BioPerl) para facilitar minha vida.

Por isso eu já não filtro o intervalo na própria regex.

Quanto ao and e o &&, o && consome menos memória que o and, por ser short circuits??

Date: Fri, 30 Nov 2012 06:22:03 -0200
From: tiago.peczenyj em gmail.com
To: rio-pm em pm.org
Subject: Re: [Rio-pm] Chaves de hash

Porra o q? To mostrando q eh diferente no contexto q eu conheco...
Em 29/11/2012 23:14, "Blabos de Blebe" <blabos em gmail.com> escreveu:

Porra PAC, não pisa fora da faixa, cara! :)



http://perldoc.perl.org/perlop.html#Operator-Precedence-and-Associativity



É só aplicar as regras de precedência.



Parafraseando o perldoc, and é 'equivalent to && except for the very

low precedence'



É óbvio gente. Assim vcs me envergonham!



Game over.



2012/11/29 Tiago Peczenyj <tiago.peczenyj em gmail.com>:

> 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

>

> _______________________________________________

> 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



_______________________________________________
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/20121130/b9455c65/attachment-0001.html>


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