Hola Esteban, > > > > Bueno, antes de decidir si se comentan o no los métodos tendríamos que > > > > diferenciar muy bien método de mensaje. > > > > > > Creia tenerlo claro, pero segun lo entiendo el método es la > > > implementación del comportamiento, y el mensaje es quien activa dicho > > > comportamiento. > > > > > > > ¿Qué es lo que se comenta, el método o el mensaje? > > > > > > En Smalltalk sólo hay lugar para comentar el método, el mensaje sólo > > > se podría documentar en el emisor (que es quien lo instancia/envia). > > > > El emisor instancia un ENVIO de mensaje, no el mensaje en si. > > De acuerdo. > > > El mensaje es, según yo lo entiendo, un concepto... algo que podría > > enviar a alguien (aunque nadie lo envíe, el concepto del mensaje podría > > existir igual). > > Claro, pero si nadie lo envía, tampoco habria necesidad de > implementarlo, de hecho algunos mensajes se envían y no hay quien los > implemente, y sin embargo cumplen su objetivo como mensajes. Por ej > los DNU reenviados a properties de un objeto u transformados en otra > cosa (líbrame dios).
Efectivamente. Mensaje no implica ni "envío de mensaje" (esto no tiene mucho sentido, pero es válido), ni implementación del mensaje (ergo método). O, dicho de otra forma, hay más formas de implementar un mensaje que sólo los métodos. > > No estaría mal si de esta discusión sacamos una definición de que es > > Mensaje. > > Bueno, a nivel implementativo la diferencia entre Message y > MessageSend la entiendo, y a nivel uso creo que es a lo que nos > referimos cuando hacemos la diferencia entre envío y mensaje en sí. > > > > > ¿Si hay varios métodos que implementan el mismo mensaje, la > > > > documentación del mensaje no estaría duplicada? > > > > > > El mensaje se implementa? o es el método? El mensaje se envia, y en > > > todo caso se instancia manualmente. Al menos asi lo entiendo yo (sic > > > sic, diría Nimo ;-) ) > > > > Bueno, como te decía antes, un envío de mensaje es una cosa, y el > > mensaje en si es otra... vamos a un ejemplo: > > Esto no lo entiendo. > > > > #baila -> cuando el receptor recibe el mensaje #baila este (el receptor) > > baila un tango. > > > > Envío de Mensaje: > > > diego baila. -> esto es un envío del mensaje #baila, particularmente a > > diego. > > diego es una instancia de PesimoBailador? ;-) Sip, entre otras cosas :-P > Aca comentarias el envío? No, nunca (o casi nunca) comento los envíos. > > Una implementación del mensaje (aka un Método): > > ----------------------------------------------- > > > > PesimoBailador>>baila > > "Los pésimos bailadores no hacemos mas que mover las manos" > > > > self manos mover. > > Bueno aca hay un punto interesante que aún no termino de madurar, y es > con respecto a los comentarios de métodos con selectores iguales. > ¿Deben todos tener el mismo comentario? O tener el mismo más alguna > información particular sobre ese caso. > > Por ej, imaginate tener un NullStream que seria el equivalente de un > /dev/null, nextPut: y nextPutAll: tendrian el mismo comentario que > Stream, pero con un agregado indicando que el receptor es nulo, por lo > que lo que agregas al receptor va a parar al otro lado de la galaxia. Todavía hay otro caso más: Mensajes DISTINTOS pero con el mismo selector. Ejemplo: #value (#value en Association no tiene mucho que ver con #value en Block). > > > > En CLOS uno define por un lado el mensaje, y por otro los métodos que > > > > implementan ese mensaje. En Smalltalk, en cambio, uno no define nunca > > > > (al menos como yo lo entiendo) los mensajes, sino que uno implementa > > > > métodos. > > > > > > > > ¿So? ¿Comentamos métodos o mensajes? Si se comenta el mensaje, ¿Cómo se > > > > administra la duplicación?. > > > > > > Métodos. > > > > Mensajes ;-) > > Métodos ;-) > > Pero NO envío de mensajes, sino el significado del mensaje. > > > > > Según lo veo yo: Uno NO tendría que documentar métodos (es decir: > > > > detalles de implementación) sino que debería escribir el código limpio, > > > > que se entienda SIN necesidad de comentarios (hay muchos trucos para > > > > eso, y muchos están en el libro de Kent Beck al que hacen referencia). > > > > > > Para mi, por el contrario, no deberíamos leer código, deberiamos poder > > > confiar en la intención del selector, luego en el comentario y por > > > ultimo (si está mal comentado) en la implementación en el lenguaje. > > > > Depende que estés leyendo. ¿Que querés saber?, opciones: > > > > - Que tendría que hacer *cualquier* objeto cuando recibe un envío de > > mensaje particular. Me refiero a un comentario del tipo "Los objetos > > bailan cuando reciben este mensaje". > > Yo lo trato en singular. "Inicia el baile del receptor." Porque el > sujeto de mi comentario es el método, y no la instancia del objeto, la > instancia del objeto es a lo que en los comentarios llamo como "el > receptor". > > > - Que hace UN objeto en particular cuando recibe el mensaje. Un > > comentario tipo "Los pésimos bailadores sólo sabemos mover las manos". > > Yo trato al objeto en 3ra persona, nunca escribo eso de "Me muevo > cuando recibo el mensaje", o comentarios de clase tipo "Soy un pésimo > bailador, mi función es completar el número de concurrentes a una > fiesta." > > > - O como se baila para un determinado objeto: Para que el receptor > > baile, tenemos que enviar el mensaje #mover a las manos. > > Asi no, sería un detalle de implementación. > > > > > Pero, si documentamos la intención del mensaje, tenemos que administrar > > > > la duplicación. > > > Y donde comentás un mensaje? > > En el Smalltalk actual no hay donde hacerlo, por eso que asumo que si > > comentamos mensajes vamos a tener que sufrir la duplicación. > > Todavía no me figuro donde lo comentarías. Yo no tengo, en este momento, una postura tomada... Tuve una época que comentaba todo, otra época donde no comentaba nada, y ahora estoy en el medio ;-). Sólo quería remarcar que, creo, no nos ponemos de acuerdo sobre como comentar los mensajes y/o métodos porque, en el Smalltalk actual, no se formalizan los mensajes. Ahora, en el ST actual, se puede *indirectamente* comentar un mensaje usando los comentarios de los métodos. Pero si tenemos más de 1 método para el mismo mensaje, tenemos duplicación.... O, siguiendo tu ejemplo de mensajes respondidos con DNU, directamente no tenemos donde comentar los mensajes si no hay método que lo implemente. A lo mejor habría que extender el ST para que nos oblige a definir los mensajes... esto no tiene porque ser molesto de usar si se hacen las herramientas apropiadas... tiro un esbozo como creo que podría funcionar. Ante cualquier "referencia" a un mensaje (ya sea porque escribimos un envío de mensaje, o implementamos un método), el sistema podría buscar la lista de mensajes que tengan como selector el selector escrito. Si hay sólo uno, a lo mejor se podría seleccionar directamente sin preguntar.... no lo se. En un UNICO lugar, tenemos la colección de mensajes CON sus comentarios: 1 mensaje, 1 comentario. OJO, a lo mejor tendremos 2 mensajes con el mismo selector (como el caso de #value), pero con distintos mensajes. Si tenemos eso, el senders e implementors podría ser más exacto. Repite, la idea la "tome prestada" (aka robé) de CLOS donde el lenguaje OBLIGA a declarar los mensajes por un lado, y los métodos por otro. Esa forma no me gusta mucho, porque un porcentaje importante de mensajes no tienen más que 1 método y el trabajo se duplica... por eso creo que hay que descansar en las herramientas. > > > Uno comenta el método, para _NO_ tener que leer su implementación, por > > > sencilla que sea. > > Entonces hay otra duplicación: El comentario vs. la implementación del > > método. > > Si, en algunos casos es una duplicación que brinda homogeneidad. Si algo tenemos que hacer los OO-boys, es luchar con todas nuestras fuerzas contra la duplicación. La duplicación SIEMPRE es un indicio de que las responsabilidades no están bien demarcadas. > Por > ejemplo en el caso de los accessors. Esta homogeneidad sale a la luz > cuando uno quiere autodocumentar algo. Además de los unit tests. > > Por ej, la mayor parte de los unit tests no se comentan, pues su > selector debe revelar la intención. Pero en algunos casos el selector > es un condicionante, pues no es una oración, sino un montón de > palabras amontonadas con una capitalización arbitraria (no pueden > utilizarse selectores con espacios). > > Saludos. > > Saludos, -- Diego --~--~---------~--~----~------------~-------~--~----~ Ha recibido este mensaje porque está suscrito a Grupo "clubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envíe un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups-beta.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
