"La documentation officielle est claire et traite des variables globales, locales et des propriétés comme des variantes de variables. Du point de vue de la technique, rien à redire... Mais essayons un peu de nous extraire un moment de l'écriture informatique et de nous demander ce que pouvait bien avoir dans la tête l'équipe de developpement d'AppleScript (spéculons légèrement, à défaut de pouvoir le faire sauvagement).
Il est possible que la confrontation avec Hypercard que je vais faire soit historiquement erronée, mais l'hypothèse semble toutefois fonctionner (même à tort :-)). Le rêve de Bill Atkinson était que les Hypercardiens échangent leurs piles, à savoir des fragments de connaissance; d'un point de vue informatique, un échange de données. L'échange de fonctionnalités se trouvant au fond du panier, d'un point de vue technique, était secondaire, hors les fonctions externes (justement). Donc, chacun écrit ses routines en Hypertalk et les agglutine à la queu leu-leu dans les scripts. Comment ces routines entretiennent-elles des relations les unes avec les autres ? On n'en sait que couic, hors l'auteur (et encore, pendant quelques jours... après il s'exerce, lui aussi, à l'herméneutique). Les fonctions externes possèdent par contre cette qualité de pouvoir être échangées, comme fonctionnalités, et possèdent une description des points d'entrée et de sortie qui les rendent utilisables dans des contexte variés. Mais elles ne sont pas au coeur du système.
C'est la différence avec AppleScript. Il est possible qu'historiquement les premiers AppleScripteurs furent les HyperCardiens. Force de l'inertie, la coutume perdura, qui fit construire les scripts AS autour des routines (les handlers). Puisque cela fonctionne bien ainsi, pourquoi aller voir plus loin. Je ne crois pas que cela corresponde pourtant au rêve de l'équipe de developpement d'AppleScript (rêve spéculé, je le répète), puisque l'objet script (nourri de propriétés, qui se distinguent sous cet angle des autres variables) offre un supplément de puissance étonnant à AppleScript, permettant l'échange de fragments de fonctionnalités informatique de manière très propre.
L'échange n'est pas un élément de syntaxe, et la documentation n'a pas vocation de donner dans les humanités, mais le pourquoi des dispositifs fournis est peut-être quand même à rechercher chez des auteurs en chair et en os. Certes, l'objet script apporte une plus grande lisibilité des pages de scripts, le travail est mieux structuré, mais ce n'est pas là, à mes yeux, le plus important. Cela suppose surtout une modification de comportement, hors la technique immédiate. Nous n'avons plus seulement un scripteur qui écrit face à un utilisateur potentiel, mais un jeu à trois personnes mettant en scène le scripteur, l'utilisateur et un autre scripteur virtuel, dont le premier tient compte dans son écriture de script même (mais comme il est virtuel, on n'en tient évidemment pas compte actuellement, c'est le problème). Une modification d'approche, plus qu'un complément de savoir.
Je m'explique: mettons que quelqu'un écrive un gestionnaire de plug-in pour Photoshop. Il va créer une interface permettant
d'activer ou de désactiver des éléments d'une liste affichée représentant ces plug-in dont la classe de base sera "fichier", l'activation et la désactivation consistant à déplacer des fichiers du finder d'un dossier à un autre. L'interface prête au générique, puisque c'est un cas de figure fréquent, et la manipulation de fichiers tout autant, des scripts enfants pouvant varier selon la nature des fichiers manipulés (avec les incidences sur les menus)... Un vrai magasin de fonctions ou tout le monde peut se servir (pas par copier/coller... mais par "tell script bidule" ce qui rend dynamique tout le système...) pour peu que tout soit assez bien segmenté et rendu autonome. Cela signifie ensuite une diffusion publique et sélective de certaines déclarations de scripts, de certaines propriétés qu'ils contiennent (puisque l'on peut accéder à un état des propriétés de script sans exécution de commande particulière autre que "get") et de diverses commandes susceptibles d'être publiques. C'est-à-dire rendre publique tous les points d'entrées et de sorties autorisés sous une forme que l'on pourrait nommer... dictionnaire...on les aime chez les autres (les applications) mais les récusons chez nous, pratiquants du script,...c'est quand même bizarre.
Bref, ce travail fait avec des objets scripts autorise ensuite un petit malin qui aurait l'intention de faire un gestionnaire de
compléments de pilotage de s'épargner beaucoup de travail[...]Sans les propriétés, cette manière de voir les choses ne serait pas possible."
Gwénaël Le Dréan le 12/11/2001 sur la liste AppleScript francophone
Aucun commentaire:
Enregistrer un commentaire