Que game tenga center() como una MutablePosition

[hernanconiglio]

Hola! Acá seguimos molestando!
Verificamos que el mensaje center() no está retornando el objeto de la position central del tablero cuando usamos game; sino que devuelve la posición 2@2.

Tenemos este código en el program:

En el archivo pepita.wlk se define su position como game.center():

Y al ejecutar el game, pepita aparece en 2@2 en lugar de 5@5.

Estaremos haciendo algo mal?
Gracias!

[PalumboN]

Hola @hernanconiglio !

Lo que está pasando es que pepita (y todos los objects) se inicializan al iniciar el programa, y al inicio del programa el juego es de 5x5 (redondea el centro a 2@2).

Esto cambió de la versión en Xtext, donde el objeto se inicializaba la primera vez que era referenciado (de forma lazy). Creemos que esta forma es más transparente y fácil de entender, aunque en este caso no me gusta mucho....

Un workaround es inicializar a pepita en el inicio 0@0 y después de cambiar el height y width al game (que es lo que cambia el centro) hacer pepita.position(game.center()).

---

Creo que este va a ser un problema común en los juegos, sobre todo con todos los ejemplos que ya existen y tienen este patrón.

Y eso no me gusta

Me pregunto si no podemos hacer que el center sea una MutablePosition constante y que al cambiar el width y height se mute. De esa forma todos tendrían el valor actualizado hasta que se empiecen a mover 🤔

[isaiaslafon]

The issue is that even we can change the center to mutable the references are x and y numbers that are calculated before the game starts, and not a reference to game so he can ask "heigh" and "width" to do it lazy when x and y are ask. A possible solution is make center a especial position that x and y methods are lazy, and use game height and width to calculate every time. This is less performant.
I preffer the way it is now and workaround old projects.

[facu777]

Estamos acá en el hackathon charlando entre todos con @lspigariol @asanzo @CeciC24 @FedericoEncinazSayago. No estamos de acuerdo con resolverlo con una mutable position, porque cambia el comportamiento de center. Se podría resolver con:

• Definir un contrato de orden de inicialización y respetarlo en todas las implementaciones (y documentarlo).
• Marcar como error los envíos de mensaje en las inicializaciones de variables.
• Que el código del juego se ocupe de inicializar posición del visual luego de que se inicialice el juego (o sea de forma manual).
• Agregar un método updatedCenter() que agregue otro mensaje que use mutable position.

[isaiaslafon]

I upload a branch with a B option to this issue as a draft that update all the center requested when game start, but the position is mutable and adress posible transformations. Maybe the solution is that unde the hood hack the requested positions if they are inmutables.

[isaiaslafon]

Sadly I couldn't participate today on the Hackaton.

[asanzo]

Isaias!! Gracias por ponerte esto al hombro!!!!

Me voy a permitir, si no te jode:

1. hablar en español, dado que estamos discutiendo esto en español.
2. ponerle el label "necesita discusión".

Viendo tu propuesta, me asusta un poco que sea tanto quilombo meter el feature del center actualizable, es un montón de boilerplate para lo que, en mi opinión, no es un bug.

Es esperable que la inicialización de los atributos de los objetos ocurra antes que el game. Esto que marca hernán para mí se resuelve así:

object pepita {
    var property position = game.at(0,0)
}

program PepitaGame {
     game.height(10)
     game.width(10)
     pepita.position(game.center()) // luego de setear las dimensiones del tablero.
     game.start()
     
}

[isaiaslafon]

Seguramente desde el lado de TS (en vez de Wollok Language) hay una manera más elegante o "hackera" de arribar a una solución, hay una discusión al respecto, en principio la alternativa es para recrear la feature que no genera dicho probelma en xtext para tener retrocompatibilidad.
A mis compañeros estudiantes en la universidad justamente les aviso de este problema y les doy como solución, como vos decis, usar game.origin() o que tenga un objeto que defina alto y ancho del tablero y por ende el centro correcto, o que escriban los valores "a mano" con un "game.at(x deseado, y deseado)" y listo, o actualicen position en los objetos luego de enviar "game.height(newHeight)" o "game.width(newWidth)".
La propuesta es algo que no depende de la implementación de TS o xText y tiene las condiciones requeridas: posición inmutable, centro correcto siempre, no falla antes ni después de start y funciona correcto en tests. No me parece mala decisión documentar y no solucionar por lo que mencionaste. Hya partes que repite o no usa setters para no agregar métodos innecesarios a game en wollok language o dejar instancias basura luego de dar game start.