Pour le debugger : en pharo le gestionnaire d'exceptions global lance le debugger. Pas besoin d'exécuter un bout de code explicitement en mode debug.
C'est au point qu'on peut écrire un test qui appelle une méthode qui n'existe pas, créer la méthode depuis le debugger qui apparait quand on lance les tests, continuer l'exécution, et voir le test runner passer au vert.
Inspecteur mémoire : une fenêtre qui te montre l'état d'un objet (contenu des variables d'instances) et qui permet d'interagir avec directement, au niveau d'abstraction des objets (on s'embête jamais avec la représentation en bits/octets/hexa des choses).
Modèle sémantique = en gros l'arbre abstrait : le programme est constitué de classes, contenant des méthodes, les méthodes contiennent des expressions... les instances d'une classe donnée ont telle et telle variables... quand on compile une méthode et qu'une variable n'est pas définie le compilateur va lancer une exception, que l'éditeur peut choper pour proposer à quels endroits on peut définir ladite variable, ou si par hasard ça ne serait pas une typo, etc. Chercher les appelants d'une méthode ne va pas te donner de faux positifs dans les commentaires, comme grep ferait. On peut chercher les redéfinitions d'une méthode dans les sous-classes, pas simplement trouver toutes les occurrences de /ma_methode(.*)/ dans la base de code. Vim devrait connaître tout cela pour pouvoir interagir avec un programme sans se limiter à juste de la manipulation de texte.
Les outils dont je parle n'existent que dans les IDE vraiment finement liés au langage de programmation. Hors les Smalltalks, Emacs est probablement le plus similaire dans l'approche de manipulation en direct du programme.
[^] # Re: think IDE and OS rolled into one
Posté par Damien . En réponse à la dépêche Sortie du langage Pharo et de son environnement de développement en version 3.0. Évalué à 3.
Pour le debugger : en pharo le gestionnaire d'exceptions global lance le debugger. Pas besoin d'exécuter un bout de code explicitement en mode debug.
C'est au point qu'on peut écrire un test qui appelle une méthode qui n'existe pas, créer la méthode depuis le debugger qui apparait quand on lance les tests, continuer l'exécution, et voir le test runner passer au vert.
Inspecteur mémoire : une fenêtre qui te montre l'état d'un objet (contenu des variables d'instances) et qui permet d'interagir avec directement, au niveau d'abstraction des objets (on s'embête jamais avec la représentation en bits/octets/hexa des choses).
Modèle sémantique = en gros l'arbre abstrait : le programme est constitué de classes, contenant des méthodes, les méthodes contiennent des expressions... les instances d'une classe donnée ont telle et telle variables... quand on compile une méthode et qu'une variable n'est pas définie le compilateur va lancer une exception, que l'éditeur peut choper pour proposer à quels endroits on peut définir ladite variable, ou si par hasard ça ne serait pas une typo, etc. Chercher les appelants d'une méthode ne va pas te donner de faux positifs dans les commentaires, comme grep ferait. On peut chercher les redéfinitions d'une méthode dans les sous-classes, pas simplement trouver toutes les occurrences de
/ma_methode(.*)/dans la base de code. Vim devrait connaître tout cela pour pouvoir interagir avec un programme sans se limiter à juste de la manipulation de texte.Les outils dont je parle n'existent que dans les IDE vraiment finement liés au langage de programmation. Hors les Smalltalks, Emacs est probablement le plus similaire dans l'approche de manipulation en direct du programme.