wollok
wollok copied to clipboard
uqbar-project
No puedo crear referencias locales dentro del fixture
En este caso yo quería poner la creación de la correlativa en una referencia local para que no sea tan largo el código de instanciación de la materia.
Tira You cannot declare references in this definition.
Pendiente de ver si transformamos al fixture en un método initialize o una construcción initialize que acepte variables locales
Nada que ver acá, pero si ustedes están de acuerdo yo digo que avancemos con el método como propuso Fernando. Me quedan más dudas sobre init vs. initialize. ¿@Nahuel Palumbo [email protected] qué opinás? ¿O prefieren que insistamos en que opine wollok-docentes?
El mié., 26 de jun. de 2019 a la(s) 18:06, Fernando Dodino ( [email protected]) escribió:
Pendiente de ver si transformamos al fixture en un método initialize o una construcción initialize que acepte variables locales
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1638?email_source=notifications&email_token=ABDLKONWAITFV2BX2OXWMATP4PK45A5CNFSM4HMG6D72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYU2FKI#issuecomment-506045097, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKOJETUBZEAG2CYZFY6LP4PK45ANCNFSM4HMG6D7Q .
hola @npasserini , me referenciaste pero no soy Nahuel Palumbo, te aviso por si esperabas su respuesta.
Ja, sí, es @PalumboN
Posta que si no es mucho bardo, creo que prefiero el initialize como construcción (no-social, construcción gramática), porque va a ser menos error-prone. Es decir:
- en los tests, cambiar el fixture por initialize y aceptar variables locales
- en las clases, reemplazar constructor por initialize pero sin parámetros
El otro cambio es que pondría initialize() con paréntesis, para hacerlo cercano a la idea de un método. @npasserini @PalumboN, si les parece ok, yo la semana que viene le meto mecha.
Uff, te pido disculpas @nahuel
El mié., 26 de jun. de 2019 a la(s) 18:18, Nahuel Greco ( [email protected]) escribió:
hola @npasserini https://github.com/npasserini , me referenciaste pero no soy Nahuel Palumbo, te aviso por si esperabas su respuesta.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1638?email_source=notifications&email_token=ABDLKOINRW6W26UMII3OEN3P4PMLBA5CNFSM4HMG6D72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYU3EMI#issuecomment-506049073, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKOJEAVU3R3LICZPS5MLP4PMLBANCNFSM4HMG6D7Q .
Genial!
El mié., 26 de jun. de 2019 a la(s) 18:20, Fernando Dodino ( [email protected]) escribió:
Ja, sí, es @PalumboN https://github.com/PalumboN
Posta que si no es mucho bardo, creo que prefiero el initialize como construcción (no-social, construcción gramática), porque va a ser menos error-prone. Es decir:
- en los tests, cambiar el fixture por initialize y aceptar variables locales
- en las clases, reemplazar constructor por initialize pero sin parámetros
El otro cambio es que pondría initialize() con paréntesis, para hacerlo cercano a la idea de un método. @npasserini https://github.com/npasserini @PalumboN https://github.com/PalumboN, si les parece ok, yo la semana que viene le meto mecha.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1638?email_source=notifications&email_token=ABDLKOKWHJPLQAG7XPOUFV3P4PMQVA5CNFSM4HMG6D72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYU3IFI#issuecomment-506049557, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKOL3JXULMP6A5WJRIZDP4PMQVANCNFSM4HMG6D7Q .
este es doc que arme el otro dia que nos reunimos, con una posible especificacion de la instanciacion https://docs.google.com/document/d/1DnRnRKnO3IDQya3NZJqj-U-6ICrAhgUhaqpuZfGjRFk/edit
no esta escrito lo de la homolagacion con fixture, pero lo hablamos y estabamos todos de acuerdo
de que tenga referencias locales no tengo una opinión formada, no creo que sean de uso frecuente, pero tampoco molestan. en el ejemplo del fixture que origina la conversacion, yo pondria todas las instanciaciones fuera del fixture, en la declaracion de las variables y solo el agregar materia en el fixture. De hecho, solo uso fixture cuando es indispensable. Y tambien del initialize espero lo mismo.
entre init e initalize, si bien el el doc dice otra cosa, me parece mejor el init. Es suficientemente expresivo y mas breve. Y me parece mejor que no lleve ( ), no solo para facilitar la escritura, sino para tambien diferenciarlo de los metodos y disipar dudas acerca de una eventual invocación.
El mié., 26 jun. 2019 a las 18:23, Nico Passerini ([email protected]) escribió:
Genial!
El mié., 26 de jun. de 2019 a la(s) 18:20, Fernando Dodino ( [email protected]) escribió:
Ja, sí, es @PalumboN https://github.com/PalumboN
Posta que si no es mucho bardo, creo que prefiero el initialize como construcción (no-social, construcción gramática), porque va a ser menos error-prone. Es decir:
- en los tests, cambiar el fixture por initialize y aceptar variables locales
- en las clases, reemplazar constructor por initialize pero sin parámetros
El otro cambio es que pondría initialize() con paréntesis, para hacerlo cercano a la idea de un método. @npasserini https://github.com/npasserini @PalumboN https://github.com/PalumboN, si les parece ok, yo la semana que viene le meto mecha.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/uqbar-project/wollok/issues/1638?email_source=notifications&email_token=ABDLKOKWHJPLQAG7XPOUFV3P4PMQVA5CNFSM4HMG6D72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYU3IFI#issuecomment-506049557 , or mute the thread < https://github.com/notifications/unsubscribe-auth/ABDLKOL3JXULMP6A5WJRIZDP4PMQVANCNFSM4HMG6D7Q
.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1638?email_source=notifications&email_token=ACZRXGZQJQBD3CNCXUWE3HLP4PM53A5CNFSM4HMG6D72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYU3QZQ#issuecomment-506050662, or mute the thread https://github.com/notifications/unsubscribe-auth/ACZRXG7TYPZYCJB6M6MTC7LP4PM53ANCNFSM4HMG6D7Q .
Gracias Lucas por el link, y sobre todo, por ocuparte de ensamblar todo en una especificación. Respecto a init/initialize me da lo mismo (si es una construcción no me molesta que sea initialize porque tenés autocomplete y ya, e init tampoco me parece que le saque expresividad, por eso me da lo mismo). Respecto a que no lleve paréntesis, es un buen punto el que contás y estoy entonces de acuerdo en que no los lleve. Si cerramos esta definición lo pasamos al doc y nos queda para compartir... lo cual es brillante.
Llegué! Jajajaj De acuerdo con todo!
Con respecto al issue
en el ejemplo del fixture que origina la conversacion, yo pondria todas las instanciaciones fuera del fixture, en la declaracion de las variables y solo el agregar materia en el fixture.
Sí, terminé haciendo eso, esa solución la fuimos armando "en vivo" y en un momento metí el fixture y pasé código que funcionaba desde el test y falló, lo que me llamó la atención, de ahí el issue.
Una cosa que me salta el warning respecto a mover todo a la declaración de variables, es cuando hay interdependencias entre ellas. Entiendo que acá estaría correcto el dependencia secuencial, a diferencia de en los objetos con los atributos lo cual no recomendamos (trabajando con el intérprete en JS me dí cuenta que las variables de un fixture son variables, no atributos). Entonces me entra la duda si quiero ese paralelismo que estamos hablando con el bloque init, o mejor dicho, cómo presentar las semejanzas y diferencias con las clases/objetos.
No entendí bien la diferencia que hacés entre variables y atributos. Ni tampoco por qué sería un graaan problema la dependencia secuencial.
El mié., 3 de jul. de 2019 a la(s) 15:39, Nahuel Palumbo ( [email protected]) escribió:
Llegué! Jajajaj De acuerdo con todo!
Con respecto al issue
en el ejemplo del fixture que origina la conversacion, yo pondria todas las instanciaciones fuera del fixture, en la declaracion de las variables y solo el agregar materia en el fixture.
Sí, terminé haciendo eso, esa solución la fuimos armando "en vivo" y en un momento metí el fixture y pasé código que funcionaba desde el test y falló, lo que me llamó la atención, de ahí el issue.
Una cosa que me salta el warning respecto a mover todo a la declaración de variables, es cuando hay interdependencias entre ellas. Entiendo que acá estaría correcto el dependencia secuencial, a diferencia de en los objetos con los atributos lo cual no recomendamos (trabajando con el intérprete en JS me dí cuenta que las variables de un fixture son variables, no atributos). Entonces me entra la duda si quiero ese paralelismo que estamos hablando con el bloque init, o mejor dicho, cómo presentar las semejanzas y diferencias con las clases/objetos.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1638?email_source=notifications&email_token=ABDLKOJQ3KKV2RSTMA4IACTP5TW4TA5CNFSM4HMG6D72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZFK2SQ#issuecomment-508210506, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKOITBIX4XNTL6MIWBVDP5TW4TANCNFSM4HMG6D7Q .
@PalumboN , encontré un bug en la implementación del initialize() dentro del describe. Si bien te lo toma correctamente el validador ahora, se rompe en runtime cuando querés usar referencias locales (increíble que no haya un test en wollok-language probando ésto). Ya tengo el workaround, en estos días lo subo.