Syntaxe vérifiant ou "compiler" un rubis sur les rails

test d'abord, puis code. Si vous écrivez des tests qui couvrent toutes les branches de votre application, vous obtenez l'assurance que votre code exécute et produit des résultats corrects.

Edit: Je dois souligner que la possibilité de comparer deux types, qui ne dépendent pas des noms de méthodes jusqu'à la dernière seconde, etc. sont des caractéristiques principales de Ruby.

Vous n'appelez pas une méthode autant que vous envoyez un message à un objet. L'objet est alors responsable de la détermination de la manière de gérer la méthode. Dans les rails, il est utilisé pour accéder aux colonnes de DB à Activerecord. Il n'y a pas de méthodes pour les colonnes jusqu'à ce qu'un message avec le nom de la colonne soit envoyé à l'objet.

Le typage statique de Ruby va à l'encontre du système de typage du canard. On peut souvent obtenir le polymorphisme gratuitement sans vous soucier des systèmes d'héritage / d'interface complexes.

Je suggère d'embrasser ces fonctionnalités et de compenser l'incertitude grâce à des tests

Ruby n'est pas censé être en sécurité. Cela vous permet de comparer deux objets, et c'est là qu'une grande partie de son pouvoir vient de. Les rails ne seraient pas possibles sans une telle conception dynamique.

même une langue compilée, telle que Java ou C, ne vous empêchera pas de faire == sur deux objets. Comme Ben dit, il est préférable de tester d'abord. Inspectez les structures avec qui vous travaillez. Une façon d'obtenir des informations sur un objet Ruby est d'utiliser: xxx

En général, la meilleure façon (je sais) pour éviter ce type de problème pour les langages dynamiques / scripts consiste à déplacer "logique" sur méthodes / commandes et tests d'unité d'écriture pour eux. Fondamentalement, tout ce qui peut échouer devrait être testé. Le code sur la page doit être logique muet ... Plutôt que d'afficher uniquement les éléments qui répondent à un certain critère, il devrait afficher tous les éléments et obtenir cette liste d'éléments d'une méthode qui ne renvoie que celles qui doivent être affichées. < / p>

Ruby ne vous permet pas de redéfinir l'opérateur == pour un objet. Dans Ruby 1.8, vous ne pouvez pas, Ruby 1.9 était censé faire, mais je n'ai pas pu obtenir mon script travailler pour les classes de base. Cela fonctionne bien pour des objets définis personnalisés.

class Object

  alias :equal_without_warning :==

  def ==(object)
    unless self.class == object.class
      warn("Comparing `#{self.class}' with `#{object.class}'")
    end
    equal_without_warning(object)
  end

end

Deux choses que je suggère:

Un: lisez sur IRB (ou script / console pour rails). Une pratique de développement commune dans les langues dynamiques est d'essayer des extraits de code à l'intérieur d'un interprète «en direct» (comme IRB ou la console de rails). Cette pratique remonte aux premières langues dynamiques comme Smalltalk et Lisp. Ruby-Debrug est également très utile pour les problèmes de dépannage et aurait été un moyen très facile de comprendre l'erreur dans votre exemple.

Deux: Lisez sur «Typage du canard». "Types" et les variables fonctionnent un peu différemment dans RUBY que beaucoup de gens s'y attendent. Si je comprends bien, une variable comme User.ID n'a pas de "type". La valeur pointée sur par user.id a un type, mais la variable elle-même ne le fait pas. Je crois que cela fait partie de la raison pour laquelle il n'y a pas d'outil qui vous aurait dit quelle est votre erreur avant d'exécuter le programme. Comparer ces deux variables n'est pas une erreur car les variables n'ont pas de type. user.id indiquait un entier à ce moment-là dans votre programme, mais il serait parfaitement légal d'attribuer à l'utilisateur. : -)