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:
#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. #
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.