Que el mensaje times pueda recibir bloques sin parámetro

[asanzo]

¿Habrá alguna forma de que esto sea válido?

test "Message times allows blocks without parameters and works" {
    var a = 0
    3.times({ a += 1 })
    assert.equals(3, a)
}

Ahora mismo, eso no anda. El bloque hoy debe tener un parámetro: { valor => a += 1 }, lo cual es confuso.

[PalumboN]

@fdodino @nscarcella @npasserini @lspigariol

Qué onda esto? Yo varias veces me comí este error en clase. Creo que más que la sobrecarga prefiero tener 2 métodos distintos.

[lspigariol]

una solución más contundente, sería hacer que el apply(unParametro) sobre un bloque que no espera parámetros, simplemente ignore el parámetro y evalúe sin dar error.

El vie, 24 de sep. de 2021 a la(s) 15:58, Nahuel Palumbo ( @.***) escribió:

@fdodino https://github.com/fdodino @nscarcella https://github.com/nscarcella @npasserini https://github.com/npasserini @lspigariol https://github.com/lspigariol

Qué onda esto? Yo varias veces me comí este error en clase. Creo que más que la sobrecarga prefiero tener 2 métodos distintos.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok-language/issues/73#issuecomment-926854007, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZRXGZLUEKFJHP6IEUZ6P3UDTC6NANCNFSM4R3FXEIQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[nscarcella]

@PalumboN

Creo que más que la sobrecarga prefiero tener 2 métodos distintos.

A mi no me importa mucho. Creo que prefiero la sobrecarga, pero para minimizar la polución de namespaces más que nada. Mi regla de pulgar es que si no le puedo encontrar un nombre piola a cada variante prefiero sobrecargar.

@lspigariol

una solución más contundente, sería hacer que el apply(unParametro) sobre un bloque que no espera parámetros, simplemente ignore el parámetro y evalúe sin dar error.

La verdad a mí esto me da un poco de miedo. Creo que los casos en dónde tiene sentido usar bloques con menos parámetros que los esperados son pocos y me parece más útil atajar cuándo un pibe se olvida el parámetro (imaginate el mambo que se pueden hacer con un fold...) Si querés, lo que se puede hacer es agregar un método nuevo applyAndIgnoreParameterOverflow o algo así, que se tenga que llamar a consciencia.

Para ser franco no me calienta mucho este caso de uso. Hay alguna razón para querer usar un bloque sin parámetros en lugar de sólo ponerle el parámetro e ignorarlo? (además de la comprensible paja?)

[fdodino]

totalmente de acuerdo con el joven @nscarcella . Abrir la puerta a qué Wollok funcione como javascript me hace mucho ruido....

[asanzo]

Ah, pero ¿sobrecargar no es hacer que funcione como javascript 😆 ?

Con el apply del bloque estoy un poco menos convencido que con el times. Me parece razonable que informemos cuántos parámetros se espera en un bloque en caso de ser distinto del esperado. Creo que quiero eso para un lenguaje en el que estoy aprendiendo a usar bloques/lambdas/alto orden, como decía @nscarcella .

En javascript me simpatiza, pero quizás en Wollok no.

Con el times me molesta que el default espere parámetros. Nunca lo usamos ese parámetro. Para mí el times no debería recibir un bloque con parámetros, y si lo queremos debería ser un mensaje distinto o bien sobrecargado.

El problema de cambiar el default de times es la backwards compatibility, sobretodo si no vamos por la sobrecarga sino por renombrar el método.

¿Cómo jode al sistema de tipos tener sobrecarga con tipos de bloques distintos?

[nscarcella]

Ah, pero ¿sobrecargar no es hacer que funcione como javascript 😆 ?

Je, bueno técnicamente tener objetos es hacer que funcione como Javascript. Creo que el problema pasa más por qué parte de Javascript te asusta.

Con el times me molesta que el default espere parámetros. Nunca lo usamos ese parámetro. Para mí el times no debería recibir un bloque con parámetros, y si lo queremos debería ser un mensaje distinto o bien sobrecargado.

A ver, el tema no es qué el parámetro se use poco, el tema es que alcanza un caso de necesitarlo para tener que poner el parámetro. Pensá que un parámetro es fácil de ignorar cuando sobra pero imposible de inventar cuando falta. Comparto un poco la incomodidad, pero no me parece muy distinto a cuando metemos parámetros para permitir el polimorfismo.

El problema de cambiar el default de times es la backwards compatibility, sobretodo si no vamos por la sobrecarga sino por renombrar el método.

No sé, tampoco es que el nombre times sea taaaan genial. Bah, imagino que podríamos acostumbrarnos a timesRepeat si fuera necesario... No sé qué tanto nos afecta. Yo la verdad no lo uso casi nunca el times y ahora estoy curioso sobre dónde les pasa esto que les jode tanto? Imagino que es en Game, pero tiene que ser para causar un efecto n veces que no implique iterar un conjunto... No me lo veía tan común. Capaz también podría encararse esto definiendo un mensaje de más alto nivel que cubra ese escenario.

¿Cómo jode al sistema de tipos tener sobrecarga con tipos de bloques distintos?

Entieeeeeeendo que no mucho, porque el sitema de tipos admite uniones de tipos. No parece un caso muy loco.