Good point! "Undefined" é muito forte; considerando os seus argumentos, "unexpected" é mais apropriado (até por que considera o fator humano). Por outro lado, a ordem de keys(%hash) é perfeitamente "expected", pois as chaves iguais produzem hashes iguais. Sendo assim, a única coisa totalmente "unexpected" que conheço é rand(), e olha lá :P
ABS() 2011/2/14 Eden Cardim <[email protected]> > >>>>> "Stanislaw" == Stanislaw Pusep <[email protected]> writes: > > Stanislaw> Olha, não sei quanto aos outros participantes da lista, > Stanislaw> mas eu simplesmente não consigo me ater a todos esses > Stanislaw> detalhes :( Então nunca uso esse operador que me confunde > Stanislaw> (PARA MIM, é um "Undefined Behavior"), preferindo fazer > Stanislaw> "à moda antiga" (última coluna). Enfim, sou desses caras > Stanislaw> que enchem qqer operação de ()'s, tipo: ((($x / $y) - $z) > Stanislaw> > 0). Enfim, o que quero dizer é que o Perl tem um > Stanislaw> imenso potencial de produzir código cheio de > Stanislaw> Pseudo-undefined Behavior; > > Acho que você está distorcendo o significado de "undefined", que > significa "não definido". O operador ~~ tem uma semântica bastante > complexa sim, mas o comportamento dele *é definido* para todo e qualquer > caso onde ele for utilizado, o que significa que se ele comporta-se > diferentemente da definição presente na documentação, existe um bug na > implementação. A noção de "pseudo-undefined behaviour" não faz o menor > sentido, na verdade o que você queria dizer era "behaviour > unknown/ignored by myself". Se o comportamento não fosse definido, nem > os parênteses te salvadoriam. > > Os dois casos de undefined behaviour em perl que eu consigo lembrar > nesse exato momento são: > > keys(%hash) - não define a ordem de retorno das chaves, devido a um > corolário da definição de hash maps. > > $i++ + ++$i - assim como em C, usar operadores de incremento/decremento > mais de uma vez na mesma variável, no mesmo statement, resulta em > undefined behaviour. > > Sim, perl te dá corda suficiente pra você se enforcar, mas qualquer > linguagem com uma determinada margem de flexibilidade também. C, por > exemplo, permite que você escreva em pontos arbitrários da memória (e > quem vai reclamar com você é o kernel em questão). Porém, isso é um > assunto ortogonal à definição de comportamento. > > Stanislaw> por que ninguém tem obrigação de saber todas as faces de > Stanislaw> todos os operadores; isso sem contar as L<perlvar>. > > Pra poder afirmar que existe um "undefined behaviour" dentro de uma > discussão formal sem mentir ou se equivocar, você precisa sim, no > mínimo, conhecer todas as definições existentes. > > -- > Eden Cardim > Software Engineer > +55 73 9986-3963 > edencardim.com > =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
