Hola kiko,

Las diferencias muestran algunas de las muchas diferentes
formas de ver el tema del comment en smalltalk...
Verás que en (casi?) ningún lugar se hace referencia al comment
como lo hacemos aquí (en Smalltalking y en esta lista); creo que
si alguien se refiere al comment como lo hacemos es porque
en algún momento nos escucho :-).

Volviendo a tu pregunta, creo que te estas tomando muy en
serio los comentarios escritos por personas distintas, de las
que, quizás no sabes que importancia le dan al tema.
He visto en muchas oportunidades que el autor
cambia la forma de escribir los comments, dentro del
proyecto, del paquete y con el tiempo (no siempre para
mejorar... según mi apreciación).

El retoque por mas de un autor empeora la situación,
que se agrava en forma proporcional al volumen de
comentarios escritos.
Pese a esto, lo peor que he visto siempre ha sido escrito
por personas que no ponen coments (he escuchado
argumentar que si no hay comments es mejor porque
se evita ese incremento proporcional... jajaja! parece
un chiste, pero lo he escuchado... ).

En algunos casos, además ocurre que la influencia de las
herramientas y asistentes que se usan es grande, y se ve
que los autores describen los métodos (si! los métodos!
no los mensajes!) como lo sugieren las herramientas
aunque no sea esto relevante y sea repetitivo; teniendo
esto un efecto positivo o negativo según el juicio del lector.

Por ultimo, el método utilizado de diseño (por ejemplo,
cuando se trabaja creando componentes con smalltalk)
influye sobre la forma en que se escriben los comentarios,
se presta mucha mas atención intentando "prevenir al usuario"
y esto nuevamente es bueno, malo, o muy malo :-)
según quien lo interprete.

En resumen, si usas código de personas de distintos
ámbitos productivos, "los comentarios" sobre lo que
han hecho difieren :-)
y siempre la culpa es de quien lo está usando! jajaja!

En un párrafo decías:
> Este es el mismo método en 2 diferentes ST, como
> puede verse el nombre del argumento no coincide.

No es posible que sea el mismo objeto (método)
si son dos ambientes distintos.

Por otro lado, el mismo método (el mismo objeto)
en dos lugares distintos de la jerarquía podría tener
efectos muy distintos al ejecutarse...
Incluso el mismo método en la misma clase,
en dos instantes de tiempo distintos podría tener
efectos muy distintos al ejecutarse... [*]

No pienses en métodos... pensa en mensajes.

El comment, es el comment DEL MENSAJE,
el código no se comenta.

hasta pronto,
Ale.
[*] este párrafo revela (como efecto secundario)
que el modelar elcomportamiento como un objeto
(aMethod) es una aproximación de conveniencia
y que NO debemos olvidarnos de este detalle
o pensar que realmente el comportamiento puede
ser encapsulado en un objeto.

----- Original Message -----
From: "kikote gregoris" <kikogregoris@yahoo.com.ar>
To: <smalltalking@gruposyahoo.com.ar>
Sent: Saturday, February 03, 2007 2:45 PM
Subject: [objetos] Commnet inST. Again !!!

> Hola Gente
>
> Hace algún tiempo buscando en los históricos encontré algo sobre
"Comment in Smalltalk" , incluso reenvié el mail a la lista para los que no
lo habían visto.
> Desde entonces me quede con algunas dudas.
> Una de ellas tiene que ver con esto:
>
> VS>>actionForEvent: eventName
> "Answer the action to evaluate when the event
> named <eventName> is triggered by the receiver."
> ^self eventTable
> at: eventName asSymbol
> ifAbsent: [nil]
>
>
>
> VW>>actionForEvent: anEventNameSymbol
> "Answer the action to evaluate when the event
> named <anEventNameSymbol> is triggered by the receiver."
> ^self eventTable
> at: anEventNameSymbol asSymbol
> ifAbsent: [nil]
> Este es el mismo método en 2 diferentes ST, como puede verse el nombre
del argumento no coincide.
> Esto indica una diferencia de criterio a la hora de nombrar argumentos.
> En muchas ocasiones he visto que un argumento comienza con "an o aXXXX"
y que en otros casos solo se nombra como xXXXX.
> Una de las dudas tiene que ver con eso. Cuando nombrar "an o aXXXX" o
"xXXXX".
> Ale decía:
>
> Al escribir el messagePattern del metodo, los nombres
> de los argumentos son los nombres de los objetos
> tal como los ve el receptor y no como los ve el
> contexto en que esta siendo usado!.
>
> Según esto, los dos nombres son correcto en ambos métodos, pero por que
uno empieza con "an" el otro no.
>
> Otra duda es el hecho de que en algunos ST se usa en el messagePatter
algo como esto:
>
> add: anObject
>
> "Adds the specified object to the receiver.
> Parameters:
> anObject The object to add.
> Return Value:
> anObject.
> "
>
> Si yo nombro a un argumento como el receptor necesita verlo, que sentido
tiene colocar una descripción del mismo en parameters:.
> Se supone que la forma en que esta nombrado ya lo dice todo.
> Un ejemplo donde es inecesario hacer esto:
>
> getBreakpoints: aMethodDescriptor
> "
> Returns the breakpoints for a given method descriptor.
> Parameters:
> aMethodDescriptor A MethodDescriptor.
> Return Value:
> An OrderedCollection of breakpoint lines or nil.
> "
>
>
> Además tiene sentido el Return Value: ???
> En VS el método add: anObject se ve así:
>
> VS>>add: anObject
> "Answer anObject. Add anObject after the
> last element of the receiver collection."
>
> También dice que retorna anObject pero no con un Return Value:
> Cual es la manera adecuada
>
> Se que muchas de esta dudas son sutilezas pero me interesaría saber
porque.
> Creo que el no saberlas hace que luego se vean cosas muy distintas en
los distintos ST y que el que quiere aprender nunca sepa cual es la manera
correcta de hacerlo.
>
> Esta demas decir que busque en los históricos, pero no encontré mas
referencias a este tema.
>
> saludos kiko
>
>
>
>
>
>
>
>
> ---------------------------------
> Preguntá. Respondé. Descubrí.
> Todo lo que querías saber, y lo que ni imaginabas,
> está en Yahoo! Respuestas (Beta).
> Probalo ya!