Pourquoi Ruby ne prend-il pas en charge i ++ ou i-- (opérateurs d'incrémentation / décrémentation)?

L'opérateur d'incrémentation / décrémentation pré / post ( ++et --) est une syntaxe de langage de programmation assez standard (au moins pour les langages procéduraux et orientés objet).

Pourquoi Ruby ne les prend-il pas en charge? Je comprends que vous pourriez accomplir la même chose avec +=et -=, mais il semble tout simplement bizarrement arbitraire d'exclure quelque chose comme ça, d'autant plus que c'est tellement concis et conventionnel.

Exemple:

i = 0    #=> 0
i += 1   #=> 1
i        #=> 1
i++      #=> expect 2, but as far as I can tell, 
         #=> irb ignores the second + and waits for a second number to add to i

Je comprends que Fixnumc'est immuable, mais si vous +=pouvez simplement instancier un nouveau Fixnumet le définir, pourquoi ne pas faire de même pour ++?

La cohérence des affectations contenant le =personnage est-elle la seule raison à cela, ou est-ce que je manque quelque chose?

Voici comment Matz (Yukihiro Matsumoto) l'explique dans un vieux fil :

Hi,

In message "[ruby-talk:02706] X++?"
    on 00/05/10, Aleksi Niemelä <[email protected]> writes:

|I got an idea from http://www.pragprog.com:8080/rubyfaq/rubyfaq-5.html#ss5.3
|and thought to try. I didn't manage to make "auto(in|de)crement" working so
|could somebody help here? Does this contain some errors or is the idea
|wrong?

  (1) ++ and -- are NOT reserved operator in Ruby.

  (2) C's increment/decrement operators are in fact hidden assignment.
      They affect variables, not objects.  You cannot accomplish
      assignment via method.  Ruby uses +=/-= operator instead.

  (3) self cannot be a target of assignment.  In addition, altering
      the value of integer 1 might cause severe confusion throughout
      the program.

                            matz.

Une des raisons est que jusqu'à présent, chaque opérateur d'affectation (c'est-à-dire un opérateur qui change une variable) a un =en lui. Si vous ajoutez ++et --, ce n'est plus le cas.

Une autre raison est que le comportement ++et --souvent confondent les gens. i++Exemple concret: la valeur de retour de dans votre exemple serait en fait 1, et non 2 (la nouvelle valeur de iserait cependant 2).

Ce n'est pas conventionnel dans les langages OO. En fait, il n'y ++en a pas dans Smalltalk, le langage qui a inventé le terme «programmation orientée objet» (et le langage par lequel Ruby est le plus fortement influencé). Ce que vous voulez dire, c'est qu'il est conventionnel en C et que les langages imitant de près C. Ruby a une syntaxe un peu semblable au C, mais ce n'est pas servile à adhérer aux traditions C.

Quant à savoir pourquoi ce n'est pas dans Ruby: Matz n'en voulait pas. C'est vraiment la raison ultime.

La raison pour laquelle une telle chose n'existe pas dans Smalltalk est que cela fait partie de la philosophie primordiale du langage selon laquelle l'attribution d'une variable est fondamentalement un autre type de chose que l'envoi d'un message à un objet - c'est à un niveau différent. Cette réflexion a probablement influencé Matz dans la conception de Ruby.

Il ne serait pas impossible de l'inclure dans Ruby - vous pourriez facilement écrire un préprocesseur qui transforme tout ++en +=1. mais évidemment, Matz n'aimait pas l'idée d'un opérateur qui faisait une "mission cachée". Il semble également un peu étrange d'avoir un opérateur avec un opérande entier caché à l'intérieur. Aucun autre opérateur dans la langue ne fonctionne de cette façon.

Je pense qu'il y a une autre raison: ++dans Ruby ne serait pas utile à distance comme dans C et ses successeurs directs.

La raison en est, le formot - clé: s'il est essentiel en C, il est surtout superflu en Ruby. La plupart de l'itération dans Ruby est effectuée via des méthodes Enumerable, telles que eachet maplors de l'itération dans une structure de données et une Fixnum#timesméthode, lorsque vous devez effectuer une boucle un nombre exact de fois.

En fait, pour autant que je l'ai vu, la plupart du temps +=1est utilisé par des personnes fraîchement migrées vers Ruby à partir de langages de style C.

En bref, on peut vraiment se demander si des méthodes ++et --seraient utilisées du tout.

Je pense que le raisonnement de Matz pour ne pas les aimer est qu'il remplace en fait la variable par une nouvelle.

ex:

a = SomeClass.new
def a.go
  'Bonjour'
fin
# à ce stade, vous pouvez appeler a.go
# mais si vous avez fait un a ++
# cela signifie vraiment a = a + 1
# afin que vous ne puissiez plus appeler a.go
# car vous avez perdu votre original

Maintenant, si quelqu'un pouvait le convaincre qu'il devrait simplement appeler #succ! ou quoi pas, cela aurait plus de sens et éviterait le problème. Vous pouvez le suggérer sur un noyau rubis.

Vous pouvez définir un .+opérateur d'auto-incrémentation:

class Variable
  def initialize value = nil
    @value = value
  end
  attr_accessor :value
  def method_missing *args, &blk
    @value.send(*args, &blk)
  end
  def to_s
    @value.to_s
  end

  # pre-increment ".+" when x not present
  def +(x = nil)
    x ? @value + x : @value += 1
  end
  def -(x = nil)
    x ? @value - x : @value -= 1
  end
end

i = Variable.new 5
puts i                #=> 5

# normal use of +
puts i + 4            #=> 9
puts i                #=> 5

# incrementing
puts i.+              #=> 6
puts i                #=> 6

Plus d'informations sur la "variable de classe" sont disponibles dans " Variable de classe pour incrémenter les objets Fixnum ".

Et comme l'a dit David Black dans son livre "The Well-Grounded Rubyist":

Certains objets de Ruby sont stockés dans des variables en tant que valeurs immédiates. Ceux-ci incluent des entiers, des symboles (qui ressemblent à ceci) et les objets spéciaux true, false et nil. Lorsque vous affectez l'une de ces valeurs à une variable (x = 1), la variable contient la valeur elle-même, plutôt qu'une référence à celle-ci. En termes pratiques, cela n'a pas d'importance (et cela sera souvent laissé comme implicite, plutôt que répété, dans les discussions sur les références et les sujets connexes dans ce livre). Ruby gère automatiquement le déréférencement des références d'objets; vous n'avez pas à faire de travail supplémentaire pour envoyer un message à un objet qui contient, par exemple, une référence à une chaîne, par opposition à un objet qui contient une valeur entière immédiate. Mais la règle de représentation de la valeur immédiate a quelques ramifications intéressantes, surtout en ce qui concerne les nombres entiers. D'une part, tout objet représenté comme une valeur immédiate est toujours exactement le même objet, quel que soit le nombre de variables auxquelles il est affecté. Il n'y a qu'un seul objet 100, un seul objet faux, et ainsi de suite. La nature immédiate et unique des variables liées aux entiers est à l'origine du manque d'opérateurs pré et post-incrément de Ruby - c'est-à-dire que vous ne pouvez pas faire cela dans Ruby: x = 1 x ++ # Aucun opérateur de ce type La raison en est que à la présence immédiate de 1 dans x, x ++ serait comme 1 ++, ce qui signifie que vous changeriez le nombre 1 en nombre 2 - et cela n'a aucun sens. peu importe le nombre de variables auxquelles il est affecté. Il n'y a qu'un seul objet 100, un seul objet faux, et ainsi de suite. La nature immédiate et unique des variables liées aux entiers est à l'origine du manque d'opérateurs pré et post-incrément de Ruby - c'est-à-dire que vous ne pouvez pas faire cela dans Ruby: x = 1 x ++ # Aucun opérateur de ce type La raison en est que à la présence immédiate de 1 dans x, x ++ serait comme 1 ++, ce qui signifie que vous changeriez le nombre 1 en nombre 2 - et cela n'a aucun sens. peu importe le nombre de variables auxquelles il est affecté. Il n'y a qu'un seul objet 100, un seul objet faux, et ainsi de suite. La nature immédiate et unique des variables liées aux entiers est à l'origine du manque d'opérateurs pré et post-incrément de Ruby - c'est-à-dire que vous ne pouvez pas faire cela dans Ruby: x = 1 x ++ # Aucun opérateur de ce type La raison en est que à la présence immédiate de 1 dans x, x ++ serait comme 1 ++, ce qui signifie que vous changeriez le nombre 1 en nombre 2 - et cela n'a aucun sens.

Cela ne pourrait-il pas être réalisé en ajoutant une nouvelle méthode à la classe fixnum ou Integer?

$ ruby -e 'numb=1;puts numb.next'

renvoie 2

Les méthodes "destructives" semblent être ajoutées !pour avertir les utilisateurs potentiels, donc l'ajout d'une nouvelle méthode appelée next!ferait à peu près ce qui a été demandé.

$ ruby -e 'numb=1; numb.next!; puts numb' 

renvoie 2 (puisque numb a été incrémenté)

Bien sûr, la next!méthode devrait vérifier que l'objet était une variable entière et non un nombre réel, mais cela devrait être disponible.

Vérifiez ces opérateurs de la famille C dans irb de Ruby et testez-les par vous-même:

x = 2    # x is 2
x += 2   # x is 4
x++      # x is now 8
++x      # x reverse to 4