Good point!<br>"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<br clear="all">
<br>ABS()<br><br>
<br><br><div class="gmail_quote">2011/2/14 Eden Cardim <span dir="ltr"><<a href="mailto:edencardim@gmail.com" target="_blank">edencardim@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
>>>>> "Stanislaw" == Stanislaw Pusep <<a href="mailto:creaktive@gmail.com" target="_blank">creaktive@gmail.com</a>> writes:<br>
<br>
Stanislaw> Olha, não sei quanto aos outros participantes da lista,<br>
Stanislaw> mas eu simplesmente não consigo me ater a todos esses<br>
Stanislaw> detalhes :( Então nunca uso esse operador que me confunde<br>
Stanislaw> (PARA MIM, é um "Undefined Behavior"), preferindo fazer<br>
Stanislaw> "à moda antiga" (última coluna). Enfim, sou desses caras<br>
Stanislaw> que enchem qqer operação de ()'s, tipo: ((($x / $y) - $z)<br>
Stanislaw> > 0). Enfim, o que quero dizer é que o Perl tem um<br>
Stanislaw> imenso potencial de produzir código cheio de<br>
Stanislaw> Pseudo-undefined Behavior;<br>
<br>
Acho que você está distorcendo o significado de "undefined", que<br>
significa "não definido". O operador ~~ tem uma semântica bastante<br>
complexa sim, mas o comportamento dele *é definido* para todo e qualquer<br>
caso onde ele for utilizado, o que significa que se ele comporta-se<br>
diferentemente da definição presente na documentação, existe um bug na<br>
implementação. A noção de "pseudo-undefined behaviour" não faz o menor<br>
sentido, na verdade o que você queria dizer era "behaviour<br>
unknown/ignored by myself". Se o comportamento não fosse definido, nem<br>
os parênteses te salvadoriam.<br>
<br>
Os dois casos de undefined behaviour em perl que eu consigo lembrar<br>
nesse exato momento são:<br>
<br>
keys(%hash) - não define a ordem de retorno das chaves, devido a um<br>
corolário da definição de hash maps.<br>
<br>
$i++ + ++$i - assim como em C, usar operadores de incremento/decremento<br>
mais de uma vez na mesma variável, no mesmo statement, resulta em<br>
undefined behaviour.<br>
<br>
Sim, perl te dá corda suficiente pra você se enforcar, mas qualquer<br>
linguagem com uma determinada margem de flexibilidade também. C, por<br>
exemplo, permite que você escreva em pontos arbitrários da memória (e<br>
quem vai reclamar com você é o kernel em questão). Porém, isso é um<br>
assunto ortogonal à definição de comportamento.<br>
<br>
Stanislaw> por que ninguém tem obrigação de saber todas as faces de<br>
Stanislaw> todos os operadores; isso sem contar as L<perlvar>.<br>
<br>
Pra poder afirmar que existe um "undefined behaviour" dentro de uma<br>
discussão formal sem mentir ou se equivocar, você precisa sim, no<br>
mínimo, conhecer todas as definições existentes.<br>
<font color="#888888"><br>
--<br>
Eden Cardim<br>
Software Engineer<br>
+55 73 9986-3963<br>
<a href="http://edencardim.com" target="_blank">edencardim.com</a><br>
</font><div><div></div><div>=begin disclaimer<br>
Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
</div></div></blockquote></div><br>