Reseña del Taller de Ceylon: Conceptos Basicos (y experimentos no tan basicos). Primera Parte

La evaluación   simplemente te da   porque   te da una referencia al método   del objeto  ; no lo estás invocando. En el taller más adelante vimos lo de referencias a funciones, pero aquí todavía no lo veíamos.

El método   no es igual a un cero, por eso te da false. Tal vez la solución sería que las referencias a métodos arrojaran una excepción al invocar equals, pero entonces   seguiría devolviendo cero. Tal vez entonces... que el typechecker no permita hacer comparaciones entre referencias a funciones? Pero entonces cuando quieras hacer una comparación entre dos referencias a funciones no vas a poder...

Finalmente cuando trabajas en el IDE, al hacer un hover sobre   te muestra la definición y ahí te puedes dar cuenta de por qué no funciona. La bronca es si no tienes IDE.

Varios de las métodos de Iterable como count, every, any, etc tienen una contraparte como función de nivel tope. Por ejemplo tu función   puede quedar de una sola línea:

O si lo estás pensando como que un primo es un número que no tiene ningún divisor más que 1 y él mismo, entonces:

  es una función que recibe una lista de booleans y devuelve true si cualquiera de ellos es true. Entonces le pasas la comprensión para que evalúe cada elemento de la misma y si se encuentra un true, devuelve true (y al negarlo, esPrimo devuelve false). Si le pasas un número primo, any devuelve false, y al negarlo, esPrimo devuelve true.

POR CIERTO si quieren jugar más con Ceylon y no quieren o no pueden instalar el IDE, pueden probarlo en línea, se compila en el server a javascript que se ejecuta en su navegador:

La evaluación divisores.count == 0 simplemente te da false porque divisores.count te da una referencia al método count del objeto divisores; no lo estás invocando. En el taller más adelante vimos lo de referencias a funciones, pero aquí todavía no lo veíamos.

El método count no es igual a un cero, por eso te da false.

Ok. Gracias por la aclaración. No estaba seguro de la causa raíz.

Tal vez la solución sería que las referencias a métodos arrojaran una excepción al invocar equals, pero entonces 0 == divisores.count seguiría devolviendo cero. Tal vez entonces... que el typechecker no permita hacer comparaciones entre referencias a funciones? Pero entonces cuando quieras hacer una comparación entre dos referencias a funciones no vas a poder...

Mi sugerencia ahora que me has explicado la causa seria hacer que el typechecker verifique que las referencias a funciones solo puedan ser comparadas con otras referencias a funciones.

En este caso, sugeriría que se produjera un error de tipo "Can not compare function reference "count" with constant value "0", function references can only be compared to other function references"

La justificación seria que si al comparar una referencia a función con cualquier otra cosa, el resultado siempre es "no es igual", permitir una comparación así es absurdo, seria igual que escribir directamente   ¿no?

Igual y mi sugerencia tendría la limitación conceptual de que haría a las referencias a función un tipo especial.

En Ceylon (al igual que en Ruby y en Scala) es valido escribir:

Y evalúa a false. Siempre.

Mientras que en Haskell o en C# o en Java ocurre un error en tiempo de compilacion...

Uno pensaría que si se sabe desde la compilación (como en el caso de Haskell) que ningún String será jamas igual a un Integer... pues debería ser posible cacharlo... ¿no? (En caso de Scala, se le puede pedir al compilador que mande un warning en estos casos)

En el entendido de que no hay forma por código de heredar y alterar el método "equals" de una referencia a una función (y por lo tanto es un tipo "especial") entonces creo que la mejor solución seguiría seria que fuera un error de compilación... ¿no?

Pero recuerda que   se traduce como  . Si pones la referencia al método del lado derecho, entonces qué? el compilador no sabe si lo que está del lado izquierdo puede dar true al compararse con un Callable.

Entonces terminas tratando las referencias a funciones como tipos especiales para que al final solamente resuelvas la mitad del problema, porque si escribes   sigue dando false. Y no puedes restringir que NADIE pueda compararse con una ref a función.

Pero recuerda que a == b se traduce como a.equals(b). Si pones la referencia al método del lado derecho, entonces qué? el compilador no sabe si lo que está del lado izquierdo puede dar true al compararse con un Callable.

No me queda claro como es que entonces C# o Java no tienen problema para deducir que   o   son siempre falsos.

Entonces terminas tratando las referencias a funciones como tipos especiales para que al final solamente resuelvas la mitad del problema, porque si escribes 0 == divs.count sigue dando false. Y no puedes restringir que NADIE pueda compararse con una ref a función.

No veo por que no... ¿Cómo lo logran C# y Java con los strings y los ints?

En Java (y en C#) el siguiente código no compila:

Pero obviamente esto si compila:

Estoy entendiendo bien y Ceylon siempre traduce a == en "equals" ?

Si puedo, el typechecker debe poder contestarme cual es el tipo de cada lado de la comparación, por lo tanto La solución podría ser que cuando compiles en Ceylon comparaciones de referencias a funciones con otros tipos uses == en vez de equals? (Y cuando ambos lados sean referencias a funciones uses equals)

¿No?

Sí, nosotros siempre traducimos == en una llamada a equals. Si quieres comparación de identidad tenemos el operador ===. Y si intentas comparar un entero y un string usando ese operador, te da el mismo error, prueba   en try.ceylon-lang.org y verás.

En cuanto a lo segundo: el typechecker sabe el tipo de cada lado de la comparación, pero equals recibe un Object, entonces no sabe si el objeto de la izquierda implementa equals de tal modo que pueda dar un true cuando lo de la derecha es una ref a función. A eso me refiero con que no puedes restringir eso. Tal vez lo dije mal. La frase correcta es "no podemos restringir al compilador para que impida hacer comparaciones entre un objeto y una ref a función porque no sabemos si la implementación del objeto del lado izquierdo pueda dar true con ciertas refs a funciones".

Pero bueno, suponte ahora que usáramos == en vez de equals cuando el lado izquierdo es una ref a función. Tu código seguiría dando false; cuál sería entonces tu queja? La misma, no? Entonces no soluciona nada el tratar de manera especial las refs a funciones...

Pero bueno, suponte ahora que usáramos == en vez de equals cuando el lado izquierdo es una ref a función. Tu código seguiría dando false; cuál sería entonces tu queja? La misma, no? Entonces no soluciona nada el tratar de manera especial las refs a funciones...

Ya te entendí... Mmmm

Habrá que pensar en otra cosa...

Lo mas sencillo que se me ocurre de entrada es que al poner divisores.count == 0 la palabra count debería aparecer de otro color en la expresión que la palabra size en la expresion divisores.size == 0 para advertir visualmente al usuario de que la semántica es distinta...

A ver quiero dejar claro dos puntos importantisimos que no debemos de perder de vista:

== compara Objetos
y equals compara contenido.

es decir si comparamos "caso" == "caso", nos va a dar falso ya que son objetos diferentes
pero si ponemos "caso".equals("caso") nos dara true ya que aunque son distintos objetos el contenido es el mismo.

existen variantes de los metodos como equalsIgnoredCase, que compara el contenido no importando mayusculas o minusculas.

espero que esta información les ayude.

Saluds.

abraham lo que mencionas es cierto en Java pero en C# el operador == invoca el método equals. Igual pasa en Ceylon. Por lo tanto "x"=="x" da true en esos lenguajes.

Y la definición correcta para Java es que == compara referencias. Y la realidad es que   compara lo que el implementador de la clase quiera, pero pues el contrato establece que se debe definir el criterio de igualdad entre dos objetos del mismo tipo, que generalmente consiste en comparar ciertos atributos.