Open asanzo opened 4 years ago
+1, yo también tenía esa confusión. Hay que crear un issue en wollok-language para asociarlo
Es cierto que está confuso, pero no sé si la idea es mantener ambos. Con rasta pensamos el onCollide porque las múltiples colisiones del tradicional whenCollide traían problemas. Como yo lo entiendo el otro quedó sólo como compatibilidad hacia atrás, ¿qué pasa si directamente lo deprecamos/borramos?
Si lo quieren mantener estoy de acuerdo en cambiar el nombre... aunque aparece de nuevo el problema de la retrocompatibilidad.
El mié., 9 de oct. de 2019 a la(s) 10:50, Fernando Dodino ( notifications@github.com) escribió:
+1, yo también tenía esa confusión. Hay que crear un issue en wollok-language para asociarlo
— 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/1818?email_source=notifications&email_token=ABDLKOL5YUT2YYMJY4GD6X3QNXOSXA5CNFSM4I3AOCZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAX6LTQ#issuecomment-540009934, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKONSJMNFT2OE2WYQE63QNXOSXANCNFSM4I3AOCZA .
Éste es un issue de los heavies :smile: , porque preferiría que el cambio se haga pasado este cuatri (enero, febrero, marzo 2020...) sobre todo ahora que tengo andando el TP del Pacman
De hecho, si quisiéramos ser prolijos, el plan debería ser primero deprecarlo y después eliminarlo. Si lo quieren renombrar, entonces sería crear el nuevo + deprecar y luego eliminar.
El mié., 9 de oct. de 2019 a la(s) 11:29, Fernando Dodino ( notifications@github.com) escribió:
Éste es un issue de los heavies 😄 , porque preferiría que el cambio se haga pasado este cuatri (enero, febrero, marzo 2020...) sobre todo ahora que tengo andando el TP del Pacman
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1818?email_source=notifications&email_token=ABDLKOKP6CF5RTDSJNV6FRLQNXTF3A5CNFSM4I3AOCZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAYCTLY#issuecomment-540027311, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKOIVXIHC762NWBTZR7DQNXTF3ANCNFSM4I3AOCZA .
¿Podemos agregar a Wollok warnings de deprecaciones? Podríamos tener una anotación que indique la fecha de deprecación y el mensaje al que depreca, ó algo así. Wollok podría incluso proponer ese refactor. Hmmm esto amerita issue, verdad?
O sea, me gustaría tener soportado en wollok una forma de reconocer y corregir rápidamente esos errores en los proyectos viejos. No sé. Ayer un pibe usó un mensaje para las teclas de game que recibía números ¿game.onKeyPressed ó algo así? y dije "uf, está re mal que se sigan usando cosas deprecadas".
Sí, todo eso se puede, nos vendría bien si nos ayudás a definir qué deberíamos hacer.
El vie., 11 de oct. de 2019 a la(s) 16:26, asanzo (notifications@github.com) escribió:
¿Podemos agregar a Wollok warnings de deprecaciones? Podríamos tener una anotación que indique la fecha de deprecación y el mensaje al que depreca, ó algo así. Wollok podría incluso proponer ese refactor. Hmmm esto amerita issue, verdad?
O sea, me gustaría tener soportado en wollok una forma de reconocer y corregir rápidamente esos errores en los proyectos viejos. No sé. Ayer un pibe usó un mensaje para las teclas de game que recibía números ¿game.onKeyPressed ó algo así? y dije "uf, está re mal que se sigan usando cosas deprecadas".
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1818?email_source=notifications&email_token=ABDLKOOHBGCI5HO2VPHYUF3QODHN5A5CNFSM4I3AOCZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBA7KWI#issuecomment-541193561, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDLKOKHT52NCUM6FBX2DADQODHN5ANCNFSM4I3AOCZA .
uqbar-project/wollok#1843
@PalumboN por ahora veo que sigue whenCollideDo
, avanzamos con el ticket?
Sí, avancemos. Esto va a romper los juegos actuales :( No tenemos ningún mecanismo de deprecación todavía no? Da para pensar algo de eso?
No tenemos mecanismo de deprecación, si querés nos juntamos algún día y pensamos en algo... Podemos inaugurarlo con este caso...
Me fumé un caño e hice un documento para hablar de la deprecación, como si tuviera un ejército de 100 copias de Dodino para mí: https://docs.google.com/document/d/1vWqL5N7LgE6gSD2n4kAKlvpyb7LqLwNA_rjVvTa7xi4/edit# (Rastas necesitamos uno solo: por alguna razón revisar un PR lo puede hacer en tiempo negativo, me sorprende)
En todo caso, se puede mandar todo al carajo, sólo quería crear el doc y no dejarlo en blanco XD. Puedo mandar msj a wollok-dev si les va.
es el camino @asanzo , tener un documento detallado nos permite saber cuáles son las ideas y ver qué tiempo tenemos para implementarlas. Muy groso!
no es un poco fuerte deprecarlo por un cambio de nombre? no lo tengo claro, pero me suena que deprecar es un recurso extraordinario por cuestiones de fuerza mayor, por un motivo grave, que cause algún problema, que traiga consecuencias no deseadas. se me ocurre alguna recomendacion clara de no uso, indicación de uso alternativo, y en el mejor de los casos una adecuación progresiva de los ejemplos existentes.
El mié., 6 de may. de 2020 a la(s) 15:24, Fernando Dodino ( notifications@github.com) escribió:
es el camino @asanzo https://github.com/asanzo , tener un documento detallado nos permite saber cuáles son las ideas y ver qué tiempo tenemos para implementarlas. Muy groso!
— 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-language/issues/36#issuecomment-624812588, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZRXG2P74MCCYJYZQD46MTRQGTORANCNFSM4JMLRB6A .
Yo tiré la de deprecación porque pensé que la idea era cambiar el nombre del método. Sino lo que se puede hacer es dejar los dos (como hacemos con size
y length
si mal no recuerdo).
Pero dado que en este caso es por un tema de expresividad, pensando en los usuarios, me parecía mejor no dejar los 2 métodos. En realidad esto sería lo ideal, ya que tener varios métodos para lo mismo puede resultar confuso y hace que diverjan los ejemplos y otras cosas.
Por otro lado, llevaría esta nomenclatura a otros métodos, como el onTick
, que debería ser whileTickRepeat
o algo por el estilo. El onPressDo
estaría bien.
Lo de la deprecación va en paralelo, en algún momento pensamos en tener un migrador, estamos todavía lejos de eso.
A mí personalmente me gustaría depurar los nombres, se que es molesto para los que hicieron los juegos, pero también me parece que una forma de avanzar es tener una interfaz que sea entendible y que vaya mejorando.
En la reunión de Wollok definimos que el whenCollide
queda deprecado y ser borrará en 3.0 y no tener ningún método de colisión que se escape al control de flujo del juego.
Para esto último, podemos revisar esto de nuevo una vez que hayamos charlado este issue: https://github.com/uqbar-project/wollok-language/issues/60
Me parece importante tener una buena separación en el nombre y también en el "javadoc" entre
onCollideDo
y el actualwhenCollideDo
. Hoy son casi idénticas las documentaciones y casi idénticos los nombres cuando en realidad el primero lo hace muchas veces y el segundo sólo una vez.Propongo renombrar el
game.whenCollideDo
agame.whileCollideRepeat
, y agregar a las respectivas documentaciones la comparación y alguna cosita más que falta: