Pourquoi les méthodes de la documentation Ruby sont-elles précédées d’un signe de hachage?

C’est quelque chose qui me harcèle depuis un moment. Lorsque je vois une méthode Ruby imprimée en texte, elle apparaît généralement comme:

Class#method 

ou

 #method 

Maintenant, j’utiliserais:

 Class.method 

Pourquoi toutes les méthodes Ruby sont-elles précédées d’un signe dièse? Y a-t-il une raison à cela? Juste curieux.

Depuis les documents rdoc :

Les noms de classes, les fichiers source et les noms de méthode contenant un trait de soulignement ou précédés d’un caractère de hachage sont automatiquement liés par hyperlien du texte de commentaire à leur description.

(Accentuation ajoutée.)

Notez que la convention est:

 Class#method 

plutôt que

 object#method 

Dans le code, vous auriez object.method , si object était une instance de class . La convention # n’est pas utilisée dans le code.

De la documentation RDoc :

Utilisez :: pour décrire les méthodes de classe, # pour décrire les méthodes d’instance et les utiliser. par exemple un code.

La notation # est utilisée pour faire référence à la méthode d’ instance canonique, comme Ssortingng#upcase . Le . la notation est utilisée pour faire référence à la méthode d’une instance particulière, comme myssortingng.upcase . La distinction est faite pour ne pas impliquer qu’une méthode de classe «upcase» existe.

Je viens de réaliser qu’aucune des autres réponses ne touche à l’aspect le plus sortingvial de la question: pourquoi le signe # ?

J’ai deux théories:

  1. Il peut provenir de Smalltalk, où les symboles sont écrits #sym (au lieu de :sym ) comme dans Ruby. Donc, si vous voulez faire référence à un object Method (par opposition à appeler une méthode), vous appellerez quelque chose comme Array >> #new. (Le >> est lui-même une méthode qui renvoie la méthode qui lui est passée. Donc, dans Ruby, ce serait Array.method :new .) Dans la documentation Smalltalk, les méthodes sont généralement appelées Class>>method , mais dans Ruby Class:method aurait eu plus de sens, sauf qu’elle est facilement confondue avec Class::method . Par conséquent, la Class#method été choisie.
  2. Mon autre théorie est que cela a simplement été choisi parce que # est le caractère de commentaire dans Ruby.

Une réponse définitive ne peut être donnée que par celui qui a inventé cette convention. Si cela avait été inventé pour le livre Programming Ruby , ce serait soit Dave Thomas, soit Andy Hunt, mais je doute de cela. Le livre est sorti en 2001, Ruby a commencé en 1993, comment faisaient-ils référence à des méthodes auparavant?

Toutes les réponses ci-dessus sont correctes. La seule chose que je voudrais append est que le style de documentation que vous avez dit vous serait préférable

Méthode de classe

serait facilement confondu avec les méthodes de classe. Comme vous pouvez appeler les méthodes de classe dans ruby ​​en utilisant la syntaxe ci-dessus:

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

Cela a été mentionné dans la version JS de cette question , mais il semble probable que cette nomenclature provienne de JavaDoc, où la marque de hachage est traduite directement dans une référence sur la page, par exemple href="Component.html#getComponentAt(int, int)"

La réponse de heff (que je ne peux pas commenter à cause du manque de réputation), à savoir que Ruby a suivi l’exemple de JavaDoc, est la meilleure hypothèse à mon avis. Les concepteurs JavaDoc avaient besoin ou voulaient un moyen de distinguer les qualificateurs de paquet (qu’ils utilisaient pour les points) des qualificatifs de classe (pour lesquels ils utilisaient le hachage). La syntaxe des balises @see et @link de JavaDoc ressemble à ceci:

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

Voir la documentation de la variante package.class de la balise @see de JavaDoc et la documentation de la balise @link de JavaDoc, à laquelle heff a déjà fait référence.

Dans JavaDoc, le nom du package peut souvent être omis, de sorte que seule la partie Class # rest, ce qui semble tout aussi étrange que dans Ruby, car le code Java utilise la syntaxe Class.member, tout comme Ruby.

Il serait intéressant de savoir pourquoi les concepteurs JavaDoc ont besoin de la syntaxe différente, alors que le compilateur Java fonctionne bien avec les points pour les deux objectives.