Comment remplacer un sélecteur existant dans une classe dans un autre paquet

Question

J'utilise Pharo 5.0. Dans quelques cas, j'ai trouvé une limite ou peut-être un bug dans une classe Pharo existante (par exemple, quelque chose dans DBXTalk/Garage, ou Regex-Core). Je voudrais être en mesure de modifier un sélecteur ou un ensemble de sélecteurs existant dans une classe en dehors de mon propre projet et de faire cette partie de mon paquet.

J'ai trouvé plusieurs instructions sur la façon de créer un nouveau sélecteur dans une classe à l'extérieur et se déplacer que dans mon paquet (par exemple , comme le montre cette tutorial). C'est très cool. Mais dans certains cas, je veux réellement modifier un sélecteur existant dans la classe extérieure et avoir ma copie de ce sélecteur remplacer celle de la classe extérieure quand je l'utilise. Je ne souhaite pas modifier le package pré-fourni par un tiers ou Pharo existant.

Dans GNU Smalltalk, je peux le faire tout comme une partie normale de l'extension d'une classe. Par exemple:

Kernel.MatchingRegexResults extend [ 
    at: anIndex [ 
     "My updated version of the 'official' Kernel.MatchingRegexResults#at: selector" 
     "This is part of my package so overrides the 'official' version" 
     ... 
    ] 

    foo [ 
     "My new foo selector" 
    ] 
] 

Comment puis-je faire cela dans Pharo 5.0? J'ai fait pas mal de recherches mais je n'ai pas trouvé de moyen de le faire. Les mots "extend" ou "override" n'apparaissent pas dans le Pharo par l'exemple et dans les livres de Pharo.

Answer 1

Le code dans la syntaxe GNU Smalltalk

Kernel.MatchingRegexResults extend [ 
    at: anIndex [ 
     "method body" 
    ] 
    foo [ 
     "My new foo selector" 
    ] 
] 

ressemblerait à ceci

!MatchingRegexResults methodsFor: 'protocol'! 
at: anIndex 
    "method body" 
! 
foo 
    "My new foo selector" 
! ! 

dans un jeu de changement Pharo qui peut être déposé dans du navigateur de fichiers.

Cependant, veuillez noter que dans les deux cas, GNU Smalltalk et Pharo Smalltalk, vous remplacez la version originale de la méthode dans cette classe. Dans GNU Smalltalk, vous n'êtes peut-être pas habitué à enregistrer l'image. Vous pouvez donc penser que la syntaxe extend ne modifie pas la méthode d'origine dans la classe d'origine.

En fait, c'est ce qu'il fait exactement. Avec GNU Smalltalk, vous commencez généralement avec la même vieille image non modifiée à chaque fois que vous exécutez gst.

Cela est dû au fait que l'emplacement par défaut de l'image dans GNU Smalltalk n'est pas accessible en écriture pour l'utilisateur normal. Donc, gst lit la même image en lecture seule à chaque fois, vous la modifiez en mémoire avec des définitions de classe et des extensions, votre image modifiée ne vit que temporairement pendant que votre programme est en cours d'exécution et est supprimée à la sortie du programme.

Answer 2

Veuillez noter qu'en plus de ce que Milan Vavra a écrit, toutes les méthodes d'un protocole nommé *YourPackage-(something) appartiendront au paquet YourPackage, quel que soit le paquet auquel la classe appartient. Au moins dans Squeak, il y a la convention de mettre des méthodes surchargées comme ça dans le protocole *YourPackage-override. Pharo a probablement une convention de nommage similaire. La fonction Déplacer vers un package déplace la méthode vers un tel protocole "étoilé".

Toutefois, il est déconseillé d'utiliser de telles substitutions car vous ne pouvez pas avoir deux packages fournissant simultanément une implémentation pour la même méthode.Monticello essayera de conserver à la fois la méthode originale et la méthode prioritaire (voir les expéditeurs de PackageInfo>>isOverrideCategory:), mais il est toujours possible que votre méthode de remplacement soit remplacée par des mises à jour de son package original ou vous manquerez des mises à jour de la méthode originale. . La «bonne manière» est de refactoriser la méthode originale dans l'emballage d'origine pour rendre son comportement plus facilement personnalisable.