Hola,
El otro día en mi charla de metaprogramación en la Conferencia Rails
alguien del público me preguntó sobre cómo documentar métodos
definidos dinámicamente y yo no tenía ni idea =;-) No sé si esa
persona está suscrita a la lista, pero en fin, he encontrado en la
lista de ruby-talk un truquito para hacerlo; bastante rudimentario
pero simple y que en la mayoría de los casos debería funcionar. Se
trata simplemente de definir vacíos los métodos que queramos
documentar, para que lo que luego hagamos dinámicamente no sea
definirlos sino redefinirlos. En teoría la documentación se
mantiene:
El método uno hace bla, bla, bla
def uno;end
El método dos hace bla, bla, bla
def dos; end
[ :uno, :dos ].each do |m|
define_method m do
# bla, bla, bla
end
end
Como podéis ver en el hilo
(http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-talk/110865?110733-112604),
Dave T. (autor de Rdoc si no me equivoco) le contesta que eso está
bien, pero que están pensando si meter capacidad de documentar métodos
dinámicos en Rdoc, y el hilo es de 2004 y no he encontrado nada
másasí que entiendo que no lo hicieron. En el hilo comentan lo que dije
en la charla, que debe ser difícil de hacer de forma automática, ya
que, al contrario que los métodos “normales”, estos métodos no
“existen” hasta que el código se ejecuta, cosa que Rdoc no hace ni
hará (simplemente lo parsea).
Si alguien encuentra algo más que lo diga, pero vamos, que eso puede
valer para muchos casos.
–
Sergio Gil Pérez de la Manga
e-mail > [email protected]
blog > http://www.lacoctelera.com/porras
igual estoy meando fuera del tiesto, ¿pero realmente es necesario
documentar todos y cada uno de los métodos generados de manera dinámica?
es decir, ¿en qué se distinguen los métodos ‘uno’ y ‘dos’? entiendo que
a priori compartirán gran parte del cuerpo y tendrán una funcionalidad
similar y por eso lo de generarlos de manera dinámica, asi que igual lo
que tiene sentido es documentar el método ‘creador’ y explicar lo que
hace y qué hacen los métodos dinámicos de manera general.
saludos
Sergio Gil Pérez de la Manga
escribió:> Hola,
mantiene:
end
Si alguien encuentra algo más que lo diga, pero vamos, que eso puede
valer para muchos casos.
–
/**
On 11/27/07, Borja Martín [email protected] wrote:
igual estoy meando fuera del tiesto, ¿pero realmente es necesario
documentar todos y cada uno de los métodos generados de manera dinámica?
es decir, ¿en qué se distinguen los métodos ‘uno’ y ‘dos’? entiendo que
a priori compartirán gran parte del cuerpo y tendrán una funcionalidad
similar y por eso lo de generarlos de manera dinámica, asi que igual lo
que tiene sentido es documentar el método ‘creador’ y explicar lo que
hace y qué hacen los métodos dinámicos de manera general.
Supongo que depende del caso. Si te fijas en el hilo que he enlazado,
lo que hacen es una lista de métodos que no tienen nada que ver entre
sí, y que se “forwardean” a otro objeto (algo que por cierto yo
hubiera hecho con method_missing, aunque supongo que alguna
razóntendrán para hacerlo así). El caso es que una documentación genérica
de todos esos métodos no tendrían mucho sentido, ya que tienen
funcionalidades completamente diferentes.
Aunque también en muchos casos será como tú dices.
–
Sergio Gil Pérez de la Manga
e-mail > [email protected]
blog > http://www.lacoctelera.com/porras
totalmente de acuerdo. y la verdad es que pensándolo un poco mejor,
habrá casos para los que si interesará generar una documentación, sobre
todo cuando se trata de una librería que van a usar terceros. en ese
caso sí sería mejor tener la api completamente documentada ya que al
usuario final le interesará más saber qué hacen que cómo se generan esos
métodos(que supongo que será entre cero y nada :P)
pero vamos, que será como tú dices, que habrá que evaluar cada
situación.
saludos
[email protected]
escribió:> On 11/27/07, Borja Martín [email protected] wrote:
Supongo que depende del caso. Si te fijas en el hilo que he enlazado,
lo que hacen es una lista de métodos que no tienen nada que ver entre
sí, y que se “forwardean” a otro objeto (algo que por cierto yo
hubiera hecho con method_missing, aunque supongo que alguna razón
tendrán para hacerlo así). El caso es que una documentación genérica
de todos esos métodos no tendrían mucho sentido, ya que tienen
funcionalidades completamente diferentes.
Aunque también en muchos casos será como tú dices.
–
/**