lspigariol
commented
5 years ago Recuerdo esa charla, mi posicion es que tiene que tipar a object, el == no se le niega a nadie... total da false. (ídem el contains)
El vie., 28 de dic. de 2018 12:43 a. m., Nahuel Palumbo < notifications@github.com> escribió:
@npasserini https://github.com/npasserini dijo acá https://github.com/uqbar-project/wollok/pull/1574/files/1d1ba10f8f2f7f711a6090ea08e9cc456540c985#diff-6c6981b8e61992ea5935711b68b84830 :
El test espera que el == tenga tipo (Date) => Boolean y en cambio == tiene tipo (Object) => Boolean.
Esto lo estuvimos discutiendo con en alguna charla en UTN, no sé si vos estabas, pero @asanzo https://github.com/asanzo y varios más esperaban que el == tipe como el test supone. Sin embargo, ese tipo de tipado "variante en los parámetros" es complejo porque rompe el prinipio de sustitución de Liscov. Es decir, deja de pasar que si A "es subtipo de" B entonces en cualquier lugar donde puedo recibir un B puedo recibir un A.
Ejemplo:
class Animal {
const property nombre
override equals(otro) = otro.nombre() == self.nombre()
}
class Perro inherits Animal {}
class Gato inherits Animal {}
object prueba {
const firulais = new Perro(nombre = "firulais")
method esFirulais(animal) = animal == firulais
}
test "con un animal" {
assert.equals(new Animal("alf")) // falso
}
test "con un gato" {
assert.equals(new Gato("mauricio")) // error de tipos, porque gato no se puede comparar por == con perro
}
¿Qué tipo debería tener la variable animal en esFirulais? Si yo le pongo tipo animal, entonces se puede comparar animal==firulais, pero no firulais==animal. Si le pongo tipo perro entonces me pasa lo contrario.
Ojo, yo no digo que sea imposible lo que me piden, o inválido. Hay sistemas de tipos que en lugar de usar "subtipado" usan "matching" (eg. https://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/node21.html). Simplemente es otro tipo de sistema de tipos, que cambia algunas cosas de cómo estamos acostumbrados a pensar, porque Java, Scala y la mayoría de los lenguajes con tipado estático en los que más trabajamos funcionan así. Y también tenemos el prinicipio de Liscov muy incorporado.
Pero bueno, en este momento lo más fácil es asumir que el tipo del parámetro del == es Object y por lo tanto ese test no puede ser inferido como dice el assertion.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1578, or mute the thread https://github.com/notifications/unsubscribe-auth/ALMbmweCiKoJXgxupHczSOO0BSOJ6s4iks5u9ZNNgaJpZM4Zja0y .
npasserini
@npasserini dijo acá:
El test espera que el == tenga tipo (Date) => Boolean y en cambio == tiene tipo (Object) => Boolean.
Esto lo estuvimos discutiendo con en alguna charla en UTN, no sé si vos estabas, pero @asanzo y varios más esperaban que el == tipe como el test supone. Sin embargo, ese tipo de tipado "variante en los parámetros" es complejo porque rompe el prinipio de sustitución de Liscov. Es decir, deja de pasar que si A "es subtipo de" B entonces en cualquier lugar donde puedo recibir un B puedo recibir un A.
Ejemplo:
¿Qué tipo debería tener la variable animal en esFirulais? Si yo le pongo tipo animal, entonces se puede comparar
animal==firulais, pero nofirulais==animal. Si le pongo tipo perro entonces me pasa lo contrario.Ojo, yo no digo que sea imposible lo que me piden, o inválido. Hay sistemas de tipos que en lugar de usar "subtipado" usan "matching" (eg. https://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/node21.html). Simplemente es otro tipo de sistema de tipos, que cambia algunas cosas de cómo estamos acostumbrados a pensar, porque Java, Scala y la mayoría de los lenguajes con tipado estático en los que más trabajamos funcionan así. Y también tenemos el prinicipio de Liscov muy incorporado.
Pero bueno, en este momento lo más fácil es asumir que el tipo del parámetro del == es Object y por lo tanto ese test no puede ser inferido como dice el assertion.