WKO sin referenciar permite correr el REPL

[Juancete]

Para la definición del siguiente WKO´s.

object pepita {
  var energia 

  method volar(kms){
    energia = energia + kms
  }
}

Marca como error que la variable energía debe ser reverenciada a un objeto. Igualmente puedo correr el mismo en el REPL y obtengo una referencia a NULL

Y al enviar el mensaje pepita.volar(10) el error que ocurre es

✗ Evaluation Error! wollok.lang.MessageNotUnderstoodException: an Object does not understand +(arg 0) at example.pepita.volar(kms) [example.wlk:40]

Además de no dejar correr el programa, entiendo que debería ser null el objeto que no entiende el mensaje en lugar de anObject

[fdodino]

Yo acá tengo una propuesta:

• agreguemos una configuración en LSP-IDE que nos diga si queremos levantar un proyecto que tiene errores de validación (errores no warnings). Por defecto que no, pero que se pueda cambiar. Hasta ahora me acuerdo de NicoP diciendo que me debería dejar siempre ejecutar y probar algo, yo tengo mis dudas pero configurándolo estamos todos contentes.
• después hay que tratar de toquetear execSend o send y eso está más jodido porque raisear un error hace que entre en un estado raro y no se recupera fácil, o quizás el tema esté en lang en la implementación de messageNotUnderstood. Quizás haya que agregar un método uninitializedReference que tire un error, para que no aparezca el "anObject does not understand +". La parte implementativa me gustaría charlarla hoy @PalumboN @ivojawer

[PalumboN]

Holis!! (Qué lindo ver issues tuyos @Juancete ❤️)

agreguemos una configuración en LSP-IDE que nos diga si queremos levantar un proyecto que tiene errores de validación (errores no warnings). Por defecto que no, pero que se pueda cambiar.

Yo banco a NicoP en que quiero ejecutar un programa con errores (si se puede) y que me explote en la cara (si me las mando, sino no). Ejecutar un programa es una forma de entender el error. Podemos discutir y/o agregar la config, no me opongo, pero propongo que el default sea SÍ en todo caso :P

Quizás haya que agregar un método uninitializedReference que tire un error

👆 🌟 Esto me re cabe, pero no estoy seguro de cuándo checkearlo. Debería ser cuando se accede a la variable, pero teniendo el diagrama dinámico tal vez deba ser al instanciar el objeto.

para que no aparezca el "anObject does not understand +".

Esto para mí es otro error. No se está reportando bien los mensajes a null

[Juancete]

Holis!! (Qué lindo ver issues tuyos @Juancete ❤️)

Lo lindo es el terrible trabajo que se mandaron con Wollok-TS ❤️ Realmente es excelente!

Yo banco a NicoP en que quiero ejecutar un programa con errores (si se puede) y que me explote en la cara (si me las mando, sino no). Ejecutar un programa es una forma de entender el error.

Particularmente me hizo mucho ruido tener un error (o sea, detectar un problema que sabemos que es una incongruencia) e igualmente permitirme ejecutar el código. Me dio una sensación de inconsistencia por parte del lenguaje. En todo caso si quiero que el pibe se tope con una variable sin inicializar y que pueda jugar con eso para que le detone en su trabajo práctico, tal vez lo bajaría el nivel de error a warning para que el mensaje sea otro: "Che, deberías inicializar una referencia en un WKO de movida, pero vos fíjate..."

Igualmente yo estoy opinando desde afuera pero quería contar la experiencia que tuve en el momento que encontré el bug. Tal vez dejarlo correr y que explote le sea más beneficioso al alumno.

[fdodino]

@Juancete , ayer nos juntamos con Ivo, Manuel y Nahue.

• primero corregimos el problema de an Object que tiene que ver principalmente con la implementación de Wollok TS: internamente se guarda un objeto de Wollok con un valor interno en null. Por eso el kindName (algo como el toString) estaba mostrando an Object y lo cambiamos para que diga null
• por otra parte, con las clases hicimos el agregado en la instanciación de que tenga todos sus atributos inicializados. Estuvimos a punto de implementar la misma validación para clases y singletons en init pero lamentablemente la estrategia de inicialización lazy nos complicó: primero porque si vos tenés referencias circulares se suspende la inicialización hasta que se completa el valor que está pendiente, entonces si querés preguntar por los valores se rompe al querer volver a la misma función suspendida. Y después porque aun asumiendo que lo que no se pudo calcular todavía va a devolver un valor no nulo, nos dimos cuenta de que el null no se calcula de una sino que es uno de esos valores generados en forma lazy.

Conclusión: pusimos una validación cuando se termina de buildear el environment chequeando que todos los WKO estén correctamente instanciados. Si en tu proyecto querés ejecutar el REPL para ese archivo, se va a romper diciendo que a pepita le falta inicializar la energía. Si querés correr los tests, un programa o el REPL en otro archivo, vas a poder hacerlo.