Number: eliminar el método coerceToInteger()

[fdodino]

donde sea necesario utilizar truncate(0) / isInteger

[npasserini]

¿Pero el coerce no tira excepción? ¿Por qué sacarlo? ¿Es porque ensucia la interfaz?

El mar., 1 de oct. de 2019 a la(s) 23:55, Fernando Dodino ( notifications@github.com) escribió:

donde sea necesario utilizar truncate(0) / isInteger

— 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/1828?email_source=notifications&email_token=ABDLKOLUX7RAREMAA6K43RTQMQETLA5CNFSM4I4RDSP2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HPANPDA, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKONJNJEKFAHPF2SNMFDQMQETLANCNFSM4I4RDSPQ .

[fdodino]

Del lado de Wollok los lugares donde los vi eran raros, sino polémicos:

• even de Number
• odd de Number
• isPrime de Number
• times de Number
• subList de Collection
• el único caso que estaría piola es el de Range

No me suena lógico hacer

6.5.even()

y que devuelva true. Si eso depende de una operación, es responsabilidad del que envía el mensaje even() hacer un truncate(0) previo.

No se, en todo caso discutámoslo pero me parece que con el diario del lunes, este fue chiche que no vi que nadie configurara, y si hay que unificar, me gustaría ser más simple e ir por una estrategia default (en even y odd directamente estoy devolviendo false, y en isPrime ahora que lo vi lo mismo). Si me preguntás preferiría que el lenguaje no considerara estrategias de coerción de redondeo, en favor de una salida más predecible.

[npasserini]

Yo pensé que coerce tiraba excepción si recibía un noentero. Si sólo redondea entonces no veo por qué no usar truncate. Olvidándome de eso, yo pienso

• los primeros tres ejemplos de tu lista no deberían dar true nunca, no se puede redondear. O dan false siempre o tiran excepción, creo que me gusta la segunda.
• times y subList tal vez se pueden redondear... no me jodería tirar excepción.
• range es un poco más polémico, yo creo que deberíamos aceptar rangos entre dos reales cualesquiera.

El mié., 2 de oct. de 2019 a la(s) 07:11, Fernando Dodino ( notifications@github.com) escribió:

Del lado de Wollok los lugares donde los vi eran raros, sino polémicos:

• even de Number
• odd de Number
• isPrime de Number
• times de Number
• subList de Collection
• el único caso que estaría piola es el de Range

No me suena lógico hacer

6.5.even()

y que devuelva true. Si eso depende de una operación, es responsabilidad del que envía el mensaje even() hacer un truncate(0) previo.

No se, en todo caso discutámoslo pero me parece que con el diario del lunes, este fue chiche que no vi que nadie configurara, y si hay que unificar, me gustaría ser más simple e ir por una estrategia default (en even y odd directamente estoy devolviendo false, y en isPrime ahora que lo vi lo mismo). Si me preguntás preferiría que el lenguaje no considerara estrategias de coerción de redondeo, en favor de una salida más predecible.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1828?email_source=notifications&email_token=ABDLKOIXDCIL4ZZODFZY5ZLQMRXU3A5CNFSM4I4RDSP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAEIAWI#issuecomment-537428057, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKOMPJKPVQQG7C4VUEALQMRXU3ANCNFSM4I4RDSPQ .

[fdodino]

Ah, una cosa que nunca dejé en claro: coerceToInteger() delega en un nativo que aplica la estrategia de coerción definida en el IDE: truncar, redondear hacia arriba o tirar error. Hoy en el IDE que apunto a dev, me hace:

>>> 6.5.even()
true
>>> 4.4.even()
true
>>> 4.8.even()
true

(vos de alguna manera lo inferiste, no se cómo)

Eso me trajo confusión y fui a ver cómo responden javascript y Smalltalk, ambos devuelven false:

6.5 % 2 == 0
false

y

6.5 even
false

Respecto a las definiciones, estoy de acuerdo en todas, o no tengo problemas en elegir una estrategia (veamos qué pasa con Range si lo usamos con decimales), que en todo caso permite que vuelen coerceToInteger() y coerceToPositiveInteger() y a lo sumo definimos una excepción para poder localizarle el mensaje.

[lspigariol]

a la luz de los hechos, no esta bueno que siempre trunque de prepo +1 a que odd y even den false +1 a truncar en times, subList, (en get()?) +1 a range reales, tanto en inicio y fin como en el step.

[npasserini]

Yo no sé si truncar en times y sublist, son casos medio dudosos, tal vez una excepción es más prolijo.

El mié., 2 de oct. de 2019 a la(s) 10:27, Lucas Spigariol ( notifications@github.com) escribió:

a la luz de los hechos, no esta bueno que siempre trunque de prepo +1 a que odd y even den false +1 a truncar en times, subList, (en get()?) +1 a range reales, tanto en inicio y fin como en el step.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/1828?email_source=notifications&email_token=ABDLKOPUWRP6MLNVG6G3L5LQMSOVZA5CNFSM4I4RDSP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAEXRLY#issuecomment-537491631, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKOP6NGDRWPMJM4G3B4TQMSOVZANCNFSM4I4RDSPQ .

[fdodino]

Nota para mí yo del futuro: crear este método

  /**
   * @private
   *
   * Check whether this number is integer. Throws an exception otherwise.
   */
  method checkInteger() {
    if (self !== self.coerceToInteger()) {
      throw new ArithmeticException(message = "")... => i18n se pierde
    }
  }

volar el coerceToInteger, que cada método de Wollok que llama hoy al coerceToInteger haga truncate o llame a este check. El coerceToInteger en Java queda porque lo necesitamos para ver qué hacemos con las operaciones internas, pero no se debe exponer.