Enhancement #1726 - quick fix - agregar import de un elemento no existente

[nicovio]

fixes #1726

[coveralls]

Coverage remained the same at 89.789% when pulling a6c5e2fda71689b85d266772ca0b464289ebf181 on enhancement-#1726-QuickFix-agregar-import-de-un-elemento-no-existente into 9452b510edba952d0cec3d06ac4453757f95e814 on dev.

[fdodino]

Bueno @nicovio , le hice el refactor y lo testeé. Había un temita con la biblioteca mirror, que no hace implicit import, por lo tanto no te la iba a encontrar, ahora sí funciona importar de cualquiera de las 3 bibliotecas:

Lo que hice fue principalmente unificar todo en WollokLibExtensions, agregué constantes para cada archivo, y queda en un solo lugar

• todos los archivos core
• los que se importan implícitamente
• y los que son necesarios importar
• se agregó el método importRequired para detectar si un fqn debe ser importado o está implícito en el scope de Wollok

Hay dos temas que me anoto para seguir a futuro:

• el segundo if del equals no lo entendía hasta que lo saqué y vi que para game te da como válido: "wollok.", "wollok.game.", "wollok.game.*", "wollok.game.game". Habría que detectar únicamente los fqn de elementos válidos y ofrecer el asterisco o bien el elemento a secas. Por ahora tenemos una solución good enough y sólida.
• fijate que en el último caso, estoy importando example2.pepita y luego example2.* con lo que te quedan imports redundantes. Estaría bueno cargar un issue para que detecte imports del mismo archivo y te los unifique. Pero esto a futuro, vamos por partes.

@npasserini , si te parece ok lo mergeamos a dev para que entre en el release 1.9.0.

[nicovio]

Perfecto @fdodino . Me gusta lo que hiciste.

Con respecto a los temas:

• No llegué a hablarte de eso, pero igual te diste cuenta. Era para dejar afuera esos imports que no tenían sentido.

• Sí, estaría bueno que al importar example2.* borre todos los imports individuales de example2.

[nicovio]

Estuve probando dividir matchingImports en 2 métodos:

• matchingObjects que devuelve solo los elementos que son well known objects. Este lo usaría quickFixForUnresolvedRefToVariable.

• matchingClasses que devuelve solo los elementos que son clases. Este lo usaría quickFixForUnresolvedRefToClass.

Antes por ejemplo si teníamos new pitt() nos sugería importar actor.* como si tuviera una clase pitt y actor.pitt como si fuera una clase. Eso ya no pasaría.

Otro beneficio que trae esto es que ya no hace falta fijarse si es válido:

Al preguntar si es well known object (o si es clase en el caso de matchingClasses) ya se descartan todos los elementos que no van.

Es sólo una idea, después decime que te parece @fdodino.

[fdodino]

Sí, podría andar, si podés create issues distintos para cada una de las cosas que charlamos (1- diferenciar wko/object literal vs. class, evitando repetir código, 2- eliminar los imports redundantes cuando) y de paso: habría que agregar tests para esta funcionalidad (fijate la jerarquía AbstractWollokQuickFixTestCase)

[fdodino]

Yo ya mergearía este fin de semana el PR como está.

[fdodino]

@nicovio, estoy queriendo hacer un deploy este fin de semana y necesito cerrar el PR, avisame si vas a tocarlo más (yo preferiría que lo hagas en otro branch)

[nicovio]

Por mi ya pueden mergear a dev y después creo esos 2 issues que hablabamos.

@fdodino