"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