Propuesta: assert.sameClass(objeto, objeto)

[asanzo]

En el ejercicio de Tamagotchi - Mascota Virtual hay un requerimiento como este:

Cuando una mascota come, pasa lo siguiente: Si está hambrienta, se pone contenta.

Modelado con composición quedaría:

class Mascota {
    var estado = new Hambrienta()
    comer() {
          estado.come(self)
     } 
     method ponerse(_estado){
          estado = _estado
     }
     method estado() = estado
}

class Hambrienta {
     method come(mascota) {
          mascota.ponerse(contenta)
     }
     /// ......
}

class Contenta {
       // .....
}

Y desde los tests hoy proponemos hacer:

test "hambrienta come se pone contenta" {
      var mascota = new Mascota()
      mascota.comer()
      assert.equals("MascotaVirtual.Hambrienta", mascota.estado().className())
}

Cuando en realidad estaría bueno ocultar ese uso de className(), y hacerlo así:

    assert.sameClass(new Hambrienta(), mascota.estado())

De esta forma podemos evitar el pie de página que dice:

En Wollok, los objetos entienden un mensaje className(), que da el nombre de la clase. Solo puede usarse este mensaje desde los tests.

[fdodino]

Je, me gusta, yo usé kindName() y quedó peor el test porque comparo contra "a Hambrienta". Me parece bueno poder tener esa variante.

[PalumboN]

Paso por acá para decir que al final esta idea no se implementó, pero estaría bueno buscarle la vuelta. En las discusiones había salido la de tener un método que compare "estructuralmente". Podría ser

assert.simmilar(new Contenta(felicidad=2), mascota.estado())

Que verifique:

• El tipo (habría que contemplar la jerarquía)
• Los atributos (Shallow? Deep?)

¿Qué les parece?

[fdodino]

+1, aunque yo creo que la necesidad es acotada a ejercicios como el del Tamagotchi (y por ende eso refuerza mi idea de que el State pattern no es la idea de diseño que más me gusta enseñar, más en PDP)

[npasserini]

Hay que ver los detalles, pero creo que esta propuesta me cierra más que preguntar por la clase. La fácil es hacer que sea shallow, compara los atributos por igualdad estándar, pero podrías llegar al mismo problema de nuevo. La heavy es comparar los atributos de nuevo por similar, el riesgo ahí es que hay que evitar posibles ciclos, hay que armar ese algoritmo. Y también hay que chequear no meterse de nuevo en los problemas de performance que hace poco estuvo solucionando Fer.

Yo tiro una idea más fumada, para reflexionar. ¿Qué pasaría si los tests tuvieran capacidades de acceso distintas a las del resto de los objetos? Ejemplo fácil: ¿tendría sentido que un test pueda ver atributos de los objetos? Creo que este tipo de ideas no están del todo exploradas, al menos en las herramientas que yo conozco y me parece que podrían evitar que uno tenga que modificar el dominio para poder testearlo.

El mié., 24 de jul. de 2019 a la(s) 17:21, Fernando Dodino ( notifications@github.com) escribió:

+1, aunque yo creo que la necesidad es acotada a ejercicios como el del Tamagotchi (y por ende eso refuerza mi idea de que el State pattern no es la idea de diseño que más me gusta enseñar, más en PDP)

— 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/1289?email_source=notifications&email_token=ABDLKOOZ6FLCKJVEYSYAYUDQBC2WFA5CNFSM4D657U7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XP7TI#issuecomment-514785229, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDLKOJVCRPJUYHC4FVQJLDQBC2WFANCNFSM4D657U7A .

[asanzo]

Yo digo que poner un N=7 a esa profundidad de copia arregla el 99% de los problemas.

Después si quieren les cuento de dónde saqué ese nro.

[npasserini]

Yo creo que es porque calculás que cada nivel de profundidad tiene un 50% sobre el anterior. 99% es redondeo de 127/128, más preciso da 99.21%.

O bien te lo sacaste del ojete, una de dos.

El vie., 26 de jul. de 2019 a la(s) 16:37, asanzo (notifications@github.com) escribió:

Yo digo que poner un N=7 a esa profundidad de copia arregla el 99% de los problemas.

Después si quieren les cuento de dónde saqué ese nro.

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

[asanzo]

JAJAJAJAJ exacto. Ambas.

[npasserini]

Igual nuestro toString ya tiene un algoritmo más cheto para recorrer un grafo sin entrar en loop y sin recurrir a pseudoestadísticas de origen gastrointestinal, por eso yo pensaba que podía seguir la misma idea.

El vie., 26 de jul. de 2019 a la(s) 20:11, asanzo (notifications@github.com) escribió:

JAJAJAJAJ exacto. Ambas.

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

[npasserini]

No sé si da para entrar en el próximo milestone, pero al menos mirémoslo y tomemos una decisión.