Objet et philosophie

"Approche philosophique de l'objet, de Spinoza à Wittgenstein. Le modèle informatique est intermédiaire entre notre représentation mentale du monde et la texture de la réalité. Poser le concept même de l'objet revient à fonder le principe même de la descriptibilité du monde."
www.ethnoinformatique.fr


>> En savoir plus

POO

Pour prendre une analogie culinaire, l'approche classique en programmation est de rédiger des recettes, autrement dit la description des opérations à exécuter pour obtenir un résultat. Par exemple, la recette de la sauce hollandaise. Ensuite on s'avise qu'elle a beaucoup de points communs avec celle du beurre blanc, on réunit les parties communes en sous-programmes.

La Programmation Orientée Objet (POO) commence par organiser la cuisine en classifiant les objets que l'on utilise: on peut distinguer les ingrédients (que l'on consomme) et les ustensiles (que l'on réutilise). On constate que tous les ustensiles suivent un cycle commun utilisation-nettoyage-rangement à l'exception des cuisinières et autres micro-ondes qui ne passent pas au lave-vaisselle. Parmi les ustensiles, il y a des récipients, certains vont au feu, d'autres au micro-ondes et d'autres ne supportent pas d'être chauffés.

L'héritage n'est qu'une manière de décrire cette classification: une poêle à frire est un récipient qui va au feu, donc un récipient, donc un ustensile. Donc la classe poêle à frire hérite de la classe récipient qui hérite de la classe ustensile. 

Ensuite, on décrit dans les classes ce que les objets savent faire. Une cuisinière "sait" faire chauffer un récipient. Elle a donc une méthode faireChauffer qui prend comme paramètre un récipient qui va au feu (donc n'importe quel objet dont la classe hérite de la classe objetAllantauFeu). En petit-nègre informatique, cela donne dire à ma cuisinière de faireChauffer(maCasserole) ou traduit en anglais :

tell maCuisiniere to faireChauffer(maCasserole)

et si d'aventure on disait la même chose au lave-vaisselle, il répondrait : "L'objet lave-vaisselle ne comprend pas le message faireChauffer.".

La POO consiste à faire l'analyse d'un programme en termes d'objets manipulés et non de fonctions et de procédures à exécuter. C'est en s'efforçant de pratiquer cette analyse qu'on peut découvrir que les scripts-objets ont été conçus pour les gens qui suivent cette approche, et dans cette approche, leur usage est à la fois naturel et sans grand mystère.

Par contre si on reste dans l'approche classique d'une analyse procédurale, on éprouve les plus grandes difficultés à leur trouver une véritable utilité.

Laurent Sebilleau le 19/8/2004 sur applescript_fr@macplus.net 

The Zen of Python

set cmd to do shell script "python -c 'import this'"

display dialog cmd buttons {"•"} default button 1

>> Ouvrir le script dans l'éditeur

Fondations

>> The Development of AppleScript by William R. Cook

Homesickness

"I still believe that HyperCard is the best program ever written"
Steve Wozniak (Juin 2001)

HyperCard memories

"Il est assez remarquable de constater qu'Hypercard est souvent apprécié comme bonne introduction à la programmation. Personnellement, je le pratique depuis quinze ans...sans jamais penser programmation mais seulement scripting. Un bon programmeur, selon l'air du temps, fait du C, du Pascal ou autre... Scripter HyperCard c'est une affaire de novice... Ce n'est pas discutable, c'est ainsi... J'ai perdu beaucoup de temps à essayer d'expliquer autour de moi que ce n'était là que préjugés, qu'il fallait y regarder de plus près techniquement... grossière erreur de ma part. Il n'y a rien de technique là-dedans... Que l'utilisateur utilise et que le programmeur programme... Chacun à sa place, et les vaches seront bien gardées...voilà bien le non-dit. Et dans ce contexte, passer d'HyperCard au C autorise un changement de statut social (souvent fantasmé) que l'on préfère mettre au compte d'une modification de savoir.

C'est du coté de Bourdieu qu'il faut plutot chercher la compréhension de ces discussions de sourds, et considérer que l'informatique n'est pas soumise aux idéologies est assez naif (d'autant plus qu'ici, dans cet isolat numérique, il n'est pas seulement question de discours sur une pratique mais de pratique comme élément de discours, ce qui peut se révéler assez pervers, puisque l'on peut mettre ces éléments de discours au compte des faits sur lesquels on discute).

(...) Je dis qu'il est notoirement accepté que l'on ne fait rien de vraiment bon avec Hypercard...et pense que cette appréciation d'ordre technique cache en fait un verrouillage social...en gros que c'est du bourrage de crane. Il semble accepté que la différence entre outil de scripting et outil de programmation soit une différence technique...langage interprété, langage compilé, etc... cela me semble la partie résiduelle du problème... du moins pour ce qui concerne Hypercard.

Dans l'esprit de Bill Atkinson, la pratique de la programmation, sous la forme du scripting, devait être étendue à une population considérée jusqu'alors comme uniquement utilisatrice de logiciels. C'est-à-dire qu'un instituteur, un médecin, un bibliothécaire, un comptable pouvait s'approprier cette technique pour être, comme le disait si bien récemment Steve Wozniak, maître et non esclave de son ordinateur.

Chaque métier a ses particularités, et pour ne prendre qu'un seul exemple, le bibliothécaire, celui-ci ne travaille pas du tout de la même manière selon qu'il exerce dans une faculté ou un comité d'entreprise d'usine. Or comme l'outil informatique est son principal outil de travail, celui-ci se trouve enfermé, embrigadé, dans des procédures informatiques qui méconnaissent ses particularités de travail, s'il est entièrement soumis à l'outillage des logiciels standards. Cela peut geler ou assécher même ses capacités d'innovations dans son travail. Hypercard reconnaissait que son métier de base était d'être bibliothécaire et non informaticien, et lui fournissait juste ce qu'il fallait pour enrichir son travail en procédures informatiques... sans qu'il soit contraint de négliger son travail de base (s'il se met à Java...il aura tendance à ne plus en foutre une rame en matière de bibliothèque, l'ubiquité n'étant pas donnée à tout le monde...:-)). Ce "juste ce qu'il fallait" a été interprété, de manière interessée, comme une défaillance technique du produit par ceux qui entendent faire qu'un consommateur reste un consommateur.

En matière d'efficacité globale, hypercard remplissait son contrat...parce que ce qui compte, c'est ce que cela donne ... à la finale. Une comparaison entre logiciels reste incomplète si l'on n'inclut pas ce que cela donne in situ (ce qui signifie ici l'enrichissement par l'utilisateur d'hypercard du logiciel de base).

Je ne parle pas de scripting en général, mais bien d'hypercard, en particulier. Je ne dirais pas cela pour Frontier (ou Radio) par exemple...pour AppleScript, par contre le sujet est posé ;-) En d'autre terme, je ne parlais pas technique. Je disais qu'hypercard traçait le dessin d'un certain type de relation sociale potentielle autour de l'activité informatique. Son abandon correspond à une régression, de ce point de vue. Avec des effets techniques induits, évidemment (une communauté de scripteurs qui s'évapore), et là, Apple a loupé le coche."

Gwénaël Le Dréan le 01/09/2002 sur Palimpseste

Les objets 2/2

"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

Les objets 1/2

"Le script principal, celui que l'on écrit de prime abord sur une feuille vierge, est un objet de type script, à l'égal de tout autre.
La seul différence qui le différencie d'un autre est que sa déclaration (script premier ... end script) est implicite, tout comme sa commande run d'exécution. Cette omission est justifiée (mais pourrait aussi justifier sa désignation sous un nom particulier, comme superscript) par le bon sens... mais les effets induits par cette omission ont finalement éroder le sens même. Ainsi, il n'est plus fait de différence, dans la pratique courante, entre un script et ce qu'il serait préférable de nommer feuille de script, feuillet de script, formulaire de script, ou autre nom pour désigner le support physique du script et le distinguer de ce qu'il contient.

Le symptome principal de cette dérive est que l'on a l'habitude de se donner les uns les autres des superscripts (le script principal, donc) et/ou/avec des routines (ou méthodes, bref les handlers). Si le secret bien gardé d'Apple est AppleScript, le secret bien gardé d'AppleScript est l'objet de type script.

La première caractéristique d'un objet script est d'être un objet. Partant de là, la notion de Propriété n'est pas essentiellement
(quoique je reconnaisse que la documentation officielle prête légèrement (par l'emploi du mot variable, qui n'est pourtant pas faux, d'un point de vue technique) à confusion) la différence de pérennité de son état par rapport aux variables globales et locales. Cette pérennité est liée en fait, nécessairement, à la définition du mot Objet. La Propriété n'est pas essentiellement une facilité, comme outillage de programmation de mémorisation de valeurs comme les variables locales et globales, mais bien une nécessité existentielle pour un objet. Un objet "pomme", dont la propriété couleur possèderait une valeur "rouge" et la propriété grosseur possèderait une valeur "petite" qui disparaitraient toutes deux après l'exécution d'un script, perdrait, pour autant que le nombre de propriétés le caractérisant soit relativement complet, sa caractéristique d'objet reconnaissable en tant que pomme, parmi tous autres objets. La propriété ne dépend donc pas de l'exécution d'un script.

La nature de la Propriété, n'est pas inclue, à mon sens, dans une interrogation du "qu'est-ce que cela fait", mais du "qu'est-ce que cela est". C'est-à-dire que je tente, en scriptant, de décrire un espace encombré d'objets (potentiels ou réels) et non d'actions (on comprend, du coup, pourquoi une propriété est accessible de l'"extérieur"; ce qui compte est que l'objet existe).

Les actions porteront, entre autre, sur cet espace et ces objets reconnus, en modifiant notamment les valeurs des propriétés
des objets. La date de dernière sauvegarde est l'une des propriétés de l'objet backup, ainsi même que l'on peut se définir en français les propriétés nécessaires pour caractériser ce mot backup (ce qui pose vraiment la question de la définition d'un objet, en général, puisque je prend volontairement comme exemple ce qui n'est associé, en principe, qu'à une suite d'actions :)).

Je semble peut-être couper les cheveux en quatre, mais je ne le crois pas,parceque l'échange d'objets seraient autrement plus bénéfiques que l'échange de routines. Or, si nous examinons généralement attentivement le dispositif des objets que l'on manipule par script dans les applications scriptables, il est moins fréquent d'être aussi bien disposé avec les objets que l'on pourrait manipuler dans le script même, pour peu qu'on définisse justement comme objets au préalable ce que l'on triture empiriquement.

L'une des grosses critiques faite à Hypercard, qui se présentait comme application objet, était qu'il était bridé, que l'on ne pouvait pas créer (inventer) d'objets. Cette contrainte est levée avec AppleScript, en grande partie grace aux Propriétés."

Gwénaël Le Dréan le 10/11/2001 sur la liste AppleScript francophone

Bricolage et conception

"Le bricolage, consiste à partir d'une collection finie d'outils et de matériaux, à chercher comment les agencer pour réaliser quelque chose. L'idée émerge donc peu à peu des essais et de la réalisation. Le bricolage consiste à faire avec ce qu'on a sous la main, et le bricoleur collectionne volontiers des trucs et des machins qui "pourront toujours servir".
La conception consiste, au contraire, à partir d'une idée, à en faire un modèle ou un plan sans tenir compte de la disponibilité immédiate des matériaux et des outils. Le concepteur définit ses besoins puis se met en quête de ce qu'il lui faut. Il peut naturellement être amené dans la logique de sa démarche, à créer ou faire créer des outils ou des matériaux qui n'existent pas."

Laurent Sebilleau d'après Claude Levi-Strauss