Todo con el mismo nombre: program, object, test & file

[PalumboN]

En base a este issue uqbar-project/wollok-ts#96 de un juego que anda en Xtext y no en TS surgió una discusión en Discord sobre colisiones de nombres entre entidades. Enumero algunos casos de un proyecto diabólico con esta estructura:

---

game.wpgm

import wollok.game.*
program game {
	game.start()
}

• Acá hay 3 cosas que se llaman game: el program, el objeto importado y el archivo.
• En xtext esto funciona como se espera y no tira ningún Error/Warning

---

game.wtest

import wollok.game.*
describe "game" {	
	test "game" {
		game.start()
		assert.that(true)
	}
}

• Acá hay 4 cosas que se llaman game: el test, el describe, el objeto importado y el archivo.
• En xtext esto funciona como se espera y no tira ningún Error/Warning

---

game.wlk

import wollok.game.*
object game {
	method comenzar() {
		game.start()
	}
}

• Acá hay 3 cosas que se llaman game: el objeto definido, el objeto importado y el archivo.
• En xtext esto levanta pero no se le puede hablar al objeto definido, siempre referencia al importado.
  • De acá saco el los imports se imponen a las definiciones locales, cosa que me hace pensar... 🤔
• Y marca un Warning en la definición del objeto: This name is already defined (imported from game.wlk)

---

Con clases y mixines no hay problema porque los nombres comienzan en mayus y todo es case-sensitive.

Con @nscarcella acordábamos que tener el mismo nombre para distintas cosas es muy confuso (tanto para les usuaries estudiantes como para definir una especificación).

Lo primero que se me viene a la mente es que en todos los casos se ponga el warning de que hay varias cosas con el mismo nombre, como pasa con los objetos. Pero bueno, podría ser un error también.

[nscarcella]

Algunas observaciones sueltas:

import wollok.game.*
program game {
  game.start()
}

• Acá hay 3 cosas que se llaman game: el program, el objeto importado y el archivo.
• En xtext esto funciona como se espera y no tira ningún Error/Warning

Yo no estoy seguro si esto funciona como se espera. No conozco ninguna tecnología dónde un import tenga más precedencia que un scope local. Si estás adentro de un contexto que se llama "game" lo más razonable en cualquier lenguaje es que la definición local "tape" a la global.

Si ese contexto, en lugar de ser un program fuera un objeto, sería muy raro que una referencia interna a "game" siguiera apuntando al import, con lo cual los puntos que se pueden discutir acá son dos:

• Si las referencias importadas deberían ser "inocultables" (yo opino que no, aunque sea para minimizar la sorpresa con el resto del mundo)
• Si vale la pena poder referir a un "program"

El segundo punto a mi me parece el más interesante, porque entiendo que en Xtext no se puede, pero en TS sí. Mi argumento para defender que se pueda es que, si bien es definitivamente cierto que Wollok no tiene (al menos por ahora) ningún uso para referenciar a un program desde el código, sí tiene muchos casos desde afuera para referenciar a un program por su Fully Qualified Name. Si permitís poder nombrar objetos y programs con el mismo nombre dejás de tener FQN únicos y eso sumamente incómodo.

Eso por no mencionar que perderíamos la posibilidad de, el día de mañana, poder hacer cosas como unProgram.apply() y otras construcciones interesantes similares.

Pero, por encima de todo, quiero dejar super claro que incluso si Wollok te dejara hacerlo yo cagaría a pedos a un alumno que usa el mismo nombre para todo. No me parece una buena práctica, con lo cual yo quisiera más bien desincentivarla, no darle más soporte. No hay mucha diferencia entre nombrar un program "game" y nombrar una variable "else". No seas psicópata. Nombrá las cosas bien.

import wollok.game.*
describe "game" {	
  test "game" {
  	game.start()
  	assert.that(true)
  }
}

• Acá hay 4 cosas que se llaman game: el test, el describe, el objeto importado y el archivo.

No del todo. El describe y el test en TS se llaman "game", no game. Eso evita conflictos con, por ejemplo, el objeto importado. Si el test estuviera al mismo nivel que el describe (en lugar de adentro) habría un conflicto de nombres y es un conflicto que quisiera que se mantenga, porque es básicamente igual que nombrar dos test con el mismo nombre.

import wollok.game.*
object game {
method comenzar() {
game.start()
}
}

• Acá hay 3 cosas que se llaman game: el objeto definido, el objeto importado y el archivo.
• En xtext esto levanta pero no se le puede hablar al objeto definido, siempre referencia al importado.
• De acá saco el los imports se imponen a las definiciones locales, cosa que me hace pensar... 🤔

Sí, qué se yo... Esto suena más a un bug que a algo hecho a propósito y no creo que ningún lenguaje se maneje así. Llegás a meter un import * y el mundo se puede poner muy confuso muy rápido.

Además, no sé si será super frecuente, pero esto hace que el object sea básicamente irreferenciable desde un objeto anónimo:

import p.x

object x {
  const v = object {
    // Si digo "x" acá adentro va a ser SIEMPRE el x importado.
  }
}

De todos modos vale aclarar que todos los problemas "técnicos" que mencionamos tienen workarounds. Esta discusión no se trata tanto de lo que se puede hacer, sino de lo que queremos y, por ahora, lo que yo quiero es que aprendan a pararse a pensar nombres como una persona de bien.

[asanzo]

Para agregar al quilombo, está la discusión del otro día

uqbar-project/wollok-ts-cli#14

sobre los nombres de archivo y extensiones de archivo, las formas unívocas de referirse a una Entidad, y las inconsistencias que esto trae entre las validaciones existentes y el mecanismo de mergeo de packages de wollok-ts

[isaiaslafon]

Opino que se debe poner la extensión del archivo, para evitar errores, como al poner un override y no poner bien el nomrbe del método, etc. Otro probelma que me curce en Wollok en Eclipse (no me maten por decirle así) es que al redefinir un archivo y cambiar automáticamente los import a veces cambia algunos nombre que no tendría que cambiar y rompe las cosas!!! el otro punto que me paso es que si pongo el archivo en el import con la extensión da error (al menos a mí), tengo que sí o sí poner con nombre., luego el tema de los "paquetes" si game es un "objeto más un poco particular" no debería dejar crear otro que se llame igual (si mal no entendí que ahora no es así) y no se nombra de donde viene, aunque no me parece copado agregar complejidad al estudiante con tener que para cada cosas poenr de dodne viene tipo example.pepita o algo similar. Después no se que ocurre bien en los import si los hay cruzados tipo
example.wlk -> import pepita.
pepita.wlk -> import example.*
Entiendo que al correr uno u otro en el REPL usa uno único e importa los que están en él, pero en los test al hace imports imagino que descarta los imports de los wlk o qué? si no es medio raro. O están los import a "otro nivel". ???

[asanzo]

Revivo esto pues acabo de ver la grabación del taller del lunes y se volvió a discutir.

No sé si es a nivel definición del lenguaje o si es a nivel de cada implementación, pero por las discusiones abiertas estas me parece que un gran MVP sería que no se pueda tener dos nodos con el mismo nombre.

Por ejemplo, me gustaría mucho que, si sabemos que esto trae problemas, wollok-ts al compilar estalle en el momento de cargar un nodo que ya existiera. Un error bonito haría que sea mucho menos traumático encontrar problemas.

@lspigariol @nscarcella @ivojawer @PalumboN

Algo estilo "No se puede tener dos elementos con el mismo nombre "pepita" (object pepita y archivo pepita.wlk"

[nscarcella]

Yo estoy de acuerdo, aunque probablemente habría que considerar que hay diferencias entre compilar algo de cero y una recompilación incremental, donde buscas que hayan deltas sobre algo que ya existe. El jue, 1 jun 2023 a la(s) 11:00, asanzo ***@***.***) escribió:

…

Revivo esto pues acabo de ver la grabación del taller del lunes y se volvió a discutir. No sé si es a nivel definición del lenguaje o si es a nivel de cada implementación, pero por las discusiones abiertas estas me parece que un gran MVP sería que no se pueda tener dos nodos con el mismo nombre. Por ejemplo, me gustaría mucho que, si sabemos que esto trae problemas, wollok-ts al compilar estalle en el momento de cargar un nodo que ya existiera. Un error bonito haría que sea mucho menos traumático encontrar problemas. @lspigariol <https://github.com/lspigariol> @nscarcella <https://github.com/nscarcella> @ivojawer <https://github.com/ivojawer> @PalumboN <https://github.com/PalumboN> — Reply to this email directly, view it on GitHub <#122 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFPE22HCOFYOEMSQIFE733XJCN7FANCNFSM5EWQRRRQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[PalumboN]

Idem Nico. Lo tengo en cuenta, sobre todo porque el LSP es "puro" incremental.

[lspigariol]

Reavivo la discusión.

Ponerle el mismo nombre a dos elementos globales del programa es claramente un error.
Pero que eso conflictúe con los nombres de archivo es confuso para los estudiantes. Por ejemplo, no se tiene en mente que el nombre de archivo es un package con un id que puede utilizarse dentro del código, menos con la salvedad que no es el nombre sin la extensión.
cuanto más inedependiente sea el código mismo de los nombres del/los archivos donde esté escrito, mejor.

[PalumboN]

@lspigariol esto lo probaste con la útlima versión? Varios de estos issues están solucionados. Lo que tal vez choque es que marque como error que dos archivos tengan el mismo nombre (sin contar la extensión), pero debería funcionar todo (O casi! Descubrimos esto: uqbar-project/wollok-lsp-ide#168).
Si es la validación, podemos...

• Ignorarla para los archivos (y carpetas????)
• o mejorar el mensaje de error

Todo depende de cuál sea el plan a futuro... que tal vez necesitemos de una reunioncita con varios docentes.