Capítulo 21 ScalaBook, lectura imprescindible
Especialmente para programadores Java y .net, pero muy práctico para todos
Trata sobre "¿este objeto es igual que este otro?"
Dice que en Java, se ha verificado que lo raro es encontrar este método correctamente sobreescrito (muy raro)
Es muy raro encontrar un programador de Java que sobreescriba la relación de equivalencia correctamente
Y eso puede tener consecuencias muy malas
¿Qué opina Scala de todo esto?
Primero...
El libro insiste como nadie en como debe hacerse correctamente para que no te equivoques.
Eso ayuda, pero... no es una ayuda impresionante.
Por ejemplo, Groovy (lenguaje compilado pero dinámico para la máquina virtual de Java) siempre te crea un operador de igualdad y función Hash correctas, tú puedes sobreescribirlo si quieres, pero, por defecto tienes algo que funciona
Si en Scala creas "case class" en vez de class normal, Scala te creará una función Hash y operador de comparación correctos
¿Porqué sólo si es una "case class"?
Quizá por rendimiento, pero lo importante es que si no es una "case class" funciona igual de mal que Java.
Tienes una función Hash y una función de equivalencia, que sólo sirven para dar problemas
¿No sería mejor en estos casos no tener nada y que explotara en tiempo de compilación?
Sí, pero en Java, son métodos definidos en Object. Por lo tanto todos tienen que tener implementación.
Como Java NUNCA da una implementación de estos automática para tus clases, y como es muy frecuente que tus clases no necesiten estos métodos... Java opta por...
No te voy a dar el coñazo obligándote a definir unos métodos que casi nunca te sirven para nada. Yo en Object ya te doy una implementación.
Majete que es el colega... no te da por saco continuamente, pero... eso provoca uno de los mayores puntos de error en Java (porque el pobrecito no tiene ni idea en Object de como se comparan manzanas)
Error que sólo se detecta en tiempo de ejecución y puede ser difícil de encontrar
La conclusión es que Scala en este punto es mucho mejor que Java, pero sigue sin ser una solución buena (véase Groovy)
Como siempre (y en este caso también), la recomendación de Scala es... no utilices clases con estado (asignación destructiva). Eso ayuda
¿Y QUÉ PASA CON LAS TUPLAS?
Las tuplas son inmutables (no tienen estado, no tienen asignación destructiva). Empezamos bien
Aunque en el libro no recuerdo haber leído nada al respecto, he podido comprobar que Scala sí crea método de equivalencia y Hash correctamente.
Muy buena noticia
En C++ no tienen esta paranoia
pos eso, ya me diréis como lo veis
He vuelto a leer sobre paralelismo, concurrencia, tolerancia a fallos... y me paso al lado tenebroso...
Programación declarativa, esa es la solución a los problemas de hoy y sobre todo del futuro (a no ser que llegue antes la computación cuántica de forma masiva y todos al paro)
Si me dejáis (es decir, si no recibo cientos de correos pidiendo que no os torture con eso), os iré contando
Por cierto...
¿Alguien se atreve a intentar explicarme cómo se comparan dos objetos en visual basic 6?
Es curiosidad porque no tengo ni idea
No hay comentarios:
Publicar un comentario