-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Agregar validation para checkear que las consts dentro de un program esten inicializadas #175
Agregar validation para checkear que las consts dentro de un program esten inicializadas #175
Conversation
Hola @juanbono , |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GROSSO @juanbono !!! 🚀
Ahí dejé un par de comments para que vayas tomando la onda.
Cosas que me pregunto (y para comentar):
- Entiendo que para los atributos en objects y clases (y debería ser lo mismo con los mixines) está funcando como se espera (lo tocamos hace poco).
- Lo que no sé qué pasa es dentro de los bloques... Habría que checkear.
- Tal vez queremos redefinir la validación para que toda constante (no importa donde) venga inicializada. (Esto no afectaría al primer punto porque creo que los Module tienen Fields, no Variables. Pero sino bastaría con ignorar esos casos).
- Hay que cargar un issue en el LSP para la traducción. (Para mí las traducciones deberían estar acá o en lanugage, pero no en el LSP. Qué decís @fdodino?)
const isInProgram = getContainer(node)?.kind == 'Program' | ||
return !( | ||
isInProgram && | ||
!node.isAtPackageLevel && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Esto hace falta? Si isInProgram
entonces no está al nivel package.
node.value.isSynthetic && | ||
node.value.is(Literal) && | ||
node.value.isNull()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tal vez podamos abstraer esto en una función isNotInitialized
, se repite en la otra validación.
+1, eso fue una vieja discusión que perdí con @nscarcella y lo terminé implementando en wollok-lsp. Yo querría que tanto wollok-ts-cli como wollok-lsp-ide tengan internacionalización. Después wollok-ts y wollok-language pueden no tener en cuenta el idioma. |
Para mí que las validaciones devuelvan una etiqueta está bien, solo quiero los .json con las traducciones para consumirlo desde las otras apps :) |
Co-authored-by: Nahuel Palumbo <[email protected]>
@juanbono , hola! fijate cuando puedas
Gracias! |
Recién veo que el CI no está corriendo, por qué hacen falta secret keys para correr los PRs @fdodino? |
No estoy muy seguro, si pusheamos el mismo cambio desde una branch de este repo se romperá también? Ni idea por qué es necesario el secret key, porque wollok-language debería poder clonarse sin problemas ahora que lo pienso... |
@PalumboN , el #188 lo creé desde el mismo repo sin problemas. Es medio una paja, hay que ver por qué necesitamos una key para bajar el repo de language (siendo que es un repo público). Cierro este PR y la seguimos en el otro mientras. |
Arregla #151 .
El programa que use para testearlo es este y esta en este PR de wollok-language
Creen que tambien deberia checkear constantes dentro de clases, objetos y tests?