Poner false y justificar bien no estaria mal, pero tampoco estaria bien, eso es depende de quien corrija. Yo cuando trato de ayudar a algunos a preparar el final marco TODO lo que veo para no dar el pie a marcar el error, pero capaz te lo dan por bien. En prolog no es tan comun que te den codigos que no anden, de hecho, son pocos los casos.

Para justificar algo que anda podes decir los conceptos que se aplican y alcanza, en este caso con mencionar aplicacion parcial (por la funcion que se envia al map) y capaz orden superior (por el map tmb) seria suficiente.

Mira la solucion que subi yo previamente que hice otra resolucion usando orden superior, fue lo mas practico que se me ocurrio a mi, pero modificar la tupla no se si es una buena idea.

Cualquier cosa consulta

Motomine, perdon segui editando el mensaje anterior, ja!

Sobre la solucion de objetos, yo creo que si andaria, Personaje es una clase abstracta, y todos los que heredan e instancian, son clases que si implementan el energiaPorComida.
Es decir, si esa solución no anda, es un tema de smalltalk para mi, porque en cualquier lenguaje de objetos debería funcionar.
(En particular me interesa saber si esto seria bien calificado o descalificado?).

Gracias nuevamente!

Ah vi mal eso, creo que si andaria,pero conceptualmente sigue estando mal.
Si #personaje es una clase abstracta significa que fisicamente esa clase no existe, por lo que el metodo come que definiste ahi tendrias que definirlo en todas las clases que sean subclases, por lo que seguis repitiendo mucha logica ya que tendrias LO MISMO escrito n veces. Las clases abstractas son mas usadas para el diagrama y para prototipar en objetos, pero vos aca estas definiendo un metodo.

En serio? Perdon, no se smalltalk, pero es muy raro lo que me decis. Quiero decir, la cuestion de definir una clase abstracta no es solo definir una interfaz, sino, que tenga comportamiento es comun. Es decir, no hay que redefinir comer para todos los que heredan, ya lo tienen.
No veo que este mal el concepto.

O sea, una clase abstracta no se puede definir en smalltalk, hay lenguajes como java o scala que si aceptan eso.
El concepto de clase abstracta es una clase que no puede ser instanciada, pero en smalltalk (al menos hasta lo que se ve en la cursada), no se pueden crear clases abstractas.
Independientemente de eso, por mas que sea clase abstracta, vos no le podes decir que se envie un mensaje que no entiende y sus subclases si. Sigue siendo una clase, pero que no puede instanciarse.
Te aconsejaria que trates de evitar este tipo de cosas raras en el final, que no creo que te lo den del todo mal, pero no se si te lo pondran bien tampoco.

Como aprobaste la cursada sin saber smalltalk?

Pasa que la curse hace anios (2011).
Y en ese tiempo se daba clase abstracta. Y me parece que le estas pifiando con el concepto de interfaz, que eso si no se puede declarar en Smalltalk.
Si podes hacerlo, el tema es que necesitarías definir el método como interfaz para que los demás lo implemente. Pero como en smalltalk no tenes interfaz para definir metodos. Esto debería andar.
Y yo te digo, que si pido revisión y esto esta mal, te pediria que me traigas una maquina y lo probemos :/.
No es con mala onda, pero posta, parece que en lugar de evaluar los paradigmas y los conceptos se están evaluando si uno sabe programar en X lenguaje. (que esta perfecto que ensenien con esos lenguajes, y que tomen ejercicios/evaluación con eso).
Yo pienso que el concepto esta bien aplicado, es polimorfico, hay delegacion, es encapsulado, hay herencia. No veo sentido a descalificar esto. Y mas siendo que esta bien.

Lo que me mandaste es un tema de diseño, trata de no mezclar materias en el final.
Yo no digo que te lo vayan a poner mal, pero no creo que te lo den por bien.
Te lo dije en el comentario anterior, una clase abstracta no puede ser instanciada. Si vos le mandas un mensaje que la misma no entiende, eso no compilaria (al menos en los lenguajes que conozco pasa esto). En mi opinion esa respuesta no esta bien desarrollada, aunque tampoco esta mal.

Perdón por pasarte lo del template method, estuvo fuera de lugar.
Mira, yo no quiero instanciar una clase abstracta, eso es imposible. Simplemente definí un método en una clase abstracta, que llama a un método que definen las clases que heredan. Es una técnica conocida y recontra probada, por eso te pase lo del template method. Sin ningún anime de ofender. Si esto no anda en smalltalk, solamente haría falta agregar el metodo que llama, y que las clases que heredan ya estarían redefiniendo. En todo caso, esto me parece un detalle como para que te avales en esto como para decir que esta mal el desarrollo.

Te agradezco tu tiempo, y la buena voluntad que pones.
Pero estas diciendo algunas cosas mal.

(19-02-2015 21:39)Motomine escribió:  Ah vi mal eso, creo que si andaria,pero conceptualmente sigue estando mal.
Si #personaje es una clase abstracta significa que fisicamente esa clase no existe, por lo que el metodo come que definiste ahi tendrias que definirlo en todas las clases que sean subclases, por lo que seguis repitiendo mucha logica ya que tendrias LO MISMO escrito n veces. Las clases abstractas son mas usadas para el diagrama y para prototipar en objetos, pero vos aca estas definiendo un metodo.

Esta respuesta, acá estas mezclando la definición de interfaz con la clase abstracta, y encima en el lenguaje smalltalk se puede definir clases abstractas tal cual las define yo en la resolución que le di. Las interfaces, no pero es un tema del lenguaje. La mayoría de lenguajes orientados a objetos si permiten definirlas.
Lo que describis que pasaría, no es así, esta mal. La herencia justamente hace que no debas repetir ni una sola linea.

Repito, puede capaz mal interpretarse pero no le pongas ningún tono a mi comentario, solo quiero esclarecer esta confusa situación.

Desde ya gracias.

sisi aca estamos todos tratando de ayudarnos y debatiendo ideas para llegar a algo comun, no hay ningun genio. Si notase que me "atacas" o cosas asi no se seguiria debatiendo esto, asi que todo bien

Tenes razon, ahi meti la pata. Como ya dije varias veces, una clase abstracta no puede ser instanciada (ahi dije cosas que no van con la definicion). Volviendo al caso, no se que es lo que vos habras aprendido en la cursada ni que se daba. En smalltalk no se pueden definir clases abstractas como en otros lenguajes. Para hacer eso hay que hacer algo raro que no se da en la cursada y que tampoco seria clase abstracta, sino un ""metodo abstracto"".

Si bien te estan evaluando el paradigma, el mismo se enseño en un lenguaje que se usa como guia para llevar la materia. Si apareces en el final y lo desarrollas en scala usando objetos no creo que te lo den por bien, esperan que uses smalltalk. Aca creo que seria algo similar, capaz en algun lenguaje lo puedas hacer asi, pero no es un concepto propio del paradigma, sino mas del lenguaje.

Independientemente de eso, yo me atengo a que si haces eso en otro lenguaje tampoco te andaria.

Si en scala haces:

abstract class Personaje(){....} (con el metodo come que definiste vos)

class Terricola extends Personaje(){....} (con el metodo energiaPorComida)
class Extraterrestre extends Personaje(){....} (con el metodo energiaPorComida)

Las clases Terricola y Extraterrestre no tendrian problema, pero en Personaje cuando hagas this.energiaPorComida te lo marcaria, porque esta definido en las subclases y no en Personaje.

No se si me explico y no se si es eso lo a lo que te referis. Cualquier cosa corregime.

Motomine, te mandé un mail desde acá consultandote algo del final que se tomó hoy. Si tenes tiempo, por favor, leelo, quizás me podes ayudar con esa duda.
Gracias!.
Saludos