Aliás, o que explode o meu cérebro é a frase *"These rules look complicated, but usually they will do what you want."*, a respeito do "given/when", também em L<perlsyn> ;)
ABS() 2011/2/14 Stanislaw Pusep <[email protected]> > Ehehe, vou tentar contextualizar a minha lembrança... Tomo como exemplo a > "tabela-verdade" do operador ~~ ("smart matching", L<perlsyn>): > > $a $b Type of Match Implied Matching Code > ====== ===== ===================== ============= > Any undef undefined !defined $a > > Any Object invokes ~~ overloading on $object, or dies > > Hash CodeRef sub truth for each key[1] !grep { !$b->($_) } > keys %$a > Array CodeRef sub truth for each elt[1] !grep { !$b->($_) } > @$a > Any CodeRef scalar sub truth $b->($a) > > Hash Hash hash keys identical (every key is found in > both hashes) > Array Hash hash slice existence grep { exists > $b->{$_} } @$a > Regex Hash hash key grep grep /$a/, keys %$b > undef Hash always false (undef can't be a key) > Any Hash hash entry existence exists $b->{$a} > > Hash Array hash slice existence grep { exists > $a->{$_} } @$b > Array Array arrays are comparable[2] > Regex Array array grep grep /$a/, @$b > undef Array array contains undef grep !defined, @$b > Any Array match against an array element[3] > grep $a ~~ $_, @$b > > Hash Regex hash key grep grep /$b/, keys %$a > Array Regex array grep grep /$b/, @$a > Any Regex pattern match $a =~ /$b/ > > Object Any invokes ~~ overloading on $object, or falls > back: > Any Num numeric equality $a == $b > Num numish[4] numeric equality $a == $b > undef Any undefined !defined($b) > Any Any string equality $a eq $b > > 1 - empty hashes or arrays will match. > 2 - that is, each element smart-matches the element of same index > in the > other array. [3] > 3 - If a circular reference is found, we fall back to referential > equality. > 4 - either a real number, or a string that looks like a number > > Olha, não sei quanto aos outros participantes da lista, mas eu simplesmente > não consigo me ater a todos esses detalhes > :( > Então nunca uso esse operador que me confunde (*PARA MIM*, é um "*Undefined > Behavior*"), preferindo fazer "à moda antiga" (última coluna). Enfim, sou > desses caras que enchem qqer operação de ()'s, tipo: ((($x / $y) - $z) > 0). > Enfim, o que quero dizer é que o Perl tem um imenso *potencial* de > produzir código cheio de *Pseudo-undefined Behavior*; por que ninguém tem > obrigação de saber todas as faces de todos os operadores; isso sem contar as > L<perlvar>. > > > ABS() > > > > 2011/2/14 Blabos de Blebe <[email protected]> > >> Oras, isso me lembra >> >> http://www.ioccc.org/1987/wall.c >> >> Uma coisa é você usar isso em um golf, outra é usar em código de produção. >> >> Tem gente que empeteca o código com meia dúzia de regexp e se ahca 'O >> Hackerzão'. >> >> A maior parte dos bugs (com os quais estou lidando agora, por >> exemplo), teria sido evitada se fossem respeitados os padrões mínimos >> de boas práticas. Coisa que qualquer estagiário *deveria* sair da >> escolinha sabendo. >> >> Abraços >> >> 2011/2/14 Stanislaw Pusep <[email protected]>: >> > Não sei pq, mas lembrei da seguinte sintaxe, compilável em Perl: >> > >> > -f>@+?*<.-&'_:$#/%! >> > >> > ABS() >> > >> > >> > >> > 2011/2/14 Blabos de Blebe <[email protected]> >> >> >> >> Bom dia, >> >> >> >> Sem querer entrar em flames, ou no mérito da discussão, que tomo >> >> apenas como exemplo. >> >> >> >> A thread abaixo é uma discussão que está acontecendo na principal >> >> lista de C++ brasileira, sobre undefined behavior. >> >> >> >> >> >> >> http://groups.google.com/group/ccppbrasil/browse_thread/thread/9b9a7be45917095e# >> >> >> >> Notem como o Undefined behavior deste exemplo em particular pode ser >> >> resolvido com 'codificação elegante'. Ok, o assunto era outro e foi só >> >> um exemplo rápido, mas levantou a discussão que está acontecendo até >> >> agora. >> >> >> >> A maioria dos 'Undefined Behaviors' das linguagens de programação que >> >> conheço (não são muitos) são casos específicos, incomuns, bem >> >> documentados, bem avisados, normalmente abertos por 'depender da >> >> implementação' e invocados por código porco de programadores meia-boca >> >> (não que este caso de *exemplo* seja um). >> >> >> >> É claro, nenhuma linguagem é perfeita (exceto lisp), mas elas possuem >> >> especificações, mais abrangentes ou menos abrangentes. Por isso, não >> >> importa a linguagem, ou você se aprofunda e aprende, ou mais cedo ou >> >> mais tarte, vai acabar caindo em alguma dessas asrmadilhas. >> >> >> >> Na minha opinião, C tem mais armadilhas e/ou hacks que precisam de um >> >> pouco mais de conhecimento de arquitetura de computadores para escapar >> >> do que Perl, enquanto Perl tem outros tipos de armadilhas. >> >> >> >> Entenda armadilha aqui como "algo que eu imaginava de um jeito, mas >> >> aconteceu de outro", independente da expectativa ser razoável ou não. >> >> >> >> O negócio é que como Perl é mais fácil de lidar do que C, você alcança >> >> as armadilhas de Perl mais cedo do que conseguiria caminhar em C para >> >> alcançar as suas, logo, Perl parece mais imprevisível. >> >> >> >> Abraços >> >> =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 >> > >
=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
