sintaxis - ruby web

¿Por qué los métodos en la documentación de Ruby están precedidos por un signo de almohadilla?

Question

Esto es algo que me ha estado molestando por un tiempo. Cuando veo cualquier método de Ruby impreso en texto, por lo general aparece como:

Class#method

o

#method

Ahora, usaría:

Class.method

¿Por qué todos los métodos de Ruby están precedidos por un signo de libra? ¿Hay alguna razón para eso? Sólo curioso.

Answer 1

De los documentos rdoc :

Los nombres de las clases, los archivos fuente y cualquier nombre de método que contenga un guión bajo o precedido por un carácter hash se enlazan automáticamente desde el texto del comentario a su descripción.

(Énfasis añadido.)

Answer 2

Esto se mencionó en la versión JS de esta pregunta , pero parece probable que esta nomenclatura provenga de JavaDoc, donde la marca hash se traduce directamente en una referencia en la página, por ejemplo href="Component.html#getComponentAt(int, int)"

Answer 3

La notación # se usa para referirse al método de instance canónica, como String#upcase . Los . la notación se usa para referirse al método de una instancia particular, como mystring.upcase . La distinción se hace para no implicar que existe un método de clase ''upcase''.

Answer 4

Me di cuenta de que ninguna de las otras respuestas toca el aspecto más trivial de la pregunta: ¿por qué el signo # ?

Tengo dos teorías:

1. Puede provenir de Smalltalk, donde los símbolos se escriben #sym (en lugar de :sym ) tal como están en Ruby. Entonces, si quiere referirse a un objeto Method (en lugar de llamar a un método), entonces debería llamar a algo como Array >> #new. (El >> es en sí mismo un método que devuelve el método que se le pasó. Por lo tanto, en Ruby eso sería Array.method :new .) En la documentación de Smalltalk, los métodos generalmente se denominan Class>>method , pero en Ruby Class:method habría tenido más sentido, excepto que se puede confundir fácilmente con el Class::method . Por lo tanto, se eligió Class#method .
2. Mi otra teoría es que simplemente se eligió porque # es el personaje de comentarios en Ruby.

Una respuesta definitiva solo puede ser dada por quien inventó esa convención. Si fue inventado para el libro Programming Ruby , sería Dave Thomas o Andy Hunt, pero lo dudo. El libro salió en 2001, Ruby comenzó en 1993, ¿cómo se referían a los métodos antes?

Answer 5

Tenga en cuenta que la convención es:

Class#method

más bien que

object#method

En el código, tendría object.method , if object era una instancia de class . La convención # no se usa en el código.

De la documentación de RDoc :

Use :: para describir métodos de clase, # para describir métodos de instancia y uso. por ejemplo código.

Answer 6

Todas las respuestas que aparecen arriba son correctas. Lo único que agregaría es que el estilo de documentación que dijo que haría

Class.method

se confundiría fácilmente con los métodos de clase. Ya que puedes llamar a los métodos de clase en ruby ​​usando la sintaxis anterior:

class Foo
def self.say_hi
puts "hi"
end
end
Foo.say_hi # => prints "hi"

Answer 7

la respuesta de heff (que no puedo comentar debido a la falta de reputación), que Ruby siguió el ejemplo de JavaDoc, es la mejor suposición en mi opinión. Los diseñadores de JavaDoc necesitaban o querían una forma de distinguir los calificadores de paquetes (que usaban el punto) de los calificadores de clase (para los cuales usaron el hash). La sintaxis de las etiquetas @see y @link de JavaDoc se ve así:

@see package.class#member [optional label]
{@link package.class#member [optional label]}

Consulte la documentación de la variante package.class de JavaDoc de la etiqueta @see y la documentación de la etiqueta @link de JavaDoc, que Heff ya ha señalado.

En JavaDoc, el nombre del paquete a menudo se puede omitir, por lo que solo queda la parte miembro Class #, que se ve igual de extraña que en Ruby, porque el código Java usa la sintaxis Class.member, al igual que Ruby.

Sería interesante descubrir por qué los diseñadores de JavaDoc necesitaban una sintaxis diferente, mientras que el compilador de Java funciona bien con puntos para ambos propósitos.