Si, evidentemente, es un error de Ruby, incluso en el codigo de
'eql?', se ve lo siguiente:
if (memcmp(RREGEXP(re1)->str, RREGEXP(re2)->str, RREGEXP(re1)->len) == 0 &&
rb_reg_cur_kcode(re1) == rb_reg_cur_kcode(re2) &&
RREGEXP(re1)->ptr->options == RREGEXP(re2)->ptr->options) {
return Qtrue;
}
return Qfalse;
Es decir compara directamente la igualdad de options, cuando en la
documentacion dice, q hay bits de este campo q son de uso interno,
i.e., estan fuera del control del usuario.
Lo q yo planteaba es q tal vez esto podia solucionarse, en lugar de
remplazar eql? (q depaso habria q hacer lo mismo con Regexp#hash),
buscar algun otro workaround, como pasar /\d+/.freeze() , por ejemplo,
para evitar generarse algun problema nuevo debido a que algún otro
codigo o libreria se base en el comportamiento por defecto de
Regexp#eql?.
De todas formas estaria interesante q Aureliano postee el codigo donde
aparece el problema.
El 7 de julio de 2009 10:02, Rodrigo Dominguez<[email protected]> escribió:
> Yo creo que su solución, si bien fue la menos esperada, fue la mas obvia.
>
> Tenía problemas porque la key a veces no la encontraba, cuando en realidad
> estaba ahí, implemento su propio eql? para realmente encontrar la key cuando
> corresponde, y el mismo código le anda perfecto, o sea que la solución que
> planteo, si bien era la menos esperada (porque uno podría llegar a pensar
> que hay un error lógico de uno mismo antes que un comportamiento no esperado
> de ruby) es la idónea.
>
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
