AppleScript_ The Definitive Guide - Matt Neuburg [178]
It is also possible for a class to be declared as its own plural (text does this, for example). In such a case, you can use every but not a separate plural term.
Class inheritance
At an early stage in the history of AppleScript, it was observed that dictionaries were becoming large and repetitious. Several classes might share some of the very same attributes, and it seemed silly, both in the dictionary resource and in its display, to repeat the information about these attributes in the entry for each of those classes. Also, in those early days there were limits on how large a dictionary could be, so there were practical reasons for wanting to prevent unnecessary repetition.
Thus a mechanism was instituted for separating out attributes common to multiple classes. This is done by having the dictionary specify that one class inherits from another class. For example, in the Finder, there is a class item; both the file class and the container class inherit from item. This simply means that whatever properties the item class has, both the file class and the container class have also—though of course the file class and the container class might have other properties that the item class does not. The item class has a name property; therefore, so does the file class, and so does the container class. Similarly, the folder class inherits from the container class. Therefore it also inherits from item, and so a folder has a name property too. Furthermore, the container class has an entire contents property; therefore, so does the folder class. We also say that item is the superclass of file and container, and that file and container are two of its subclasses.
Thus we have a hierarchy of inheritance. An application's dictionary can include more than one such hierarchy. For example, the Finder also has a class desktop window, which inherits from Finder window, which inherits from window.
It must be stressed that this inheritance is not a true object-oriented relationship among classes! It has nothing to do with object-orientation, and it doesn't reflect any reality about how these datatypes are implemented in the application. There is no sense, in AppleScript, in which a folder "is" a container because the folder class inherits from the container class. Inheritance here is merely a notational device for expressing commonality of attributes in the dictionary.
Because of class inheritance, it is possible for a class to be abstract —that is, a class may exist only as a way of encapsulating a set of attributes so that other classes can inherit them; it is not the class of any actual object to which the programmer will ever refer. For example, BBEdit's dictionary defines an item class whose sole function is as an ultimate superclass, just so that every other class will have an ID property and a container property inherited from it; there's no property or element anywhere in the dictionary whose class is item.
The Finder, too, has an item class that acts primarily as a superclass. No Finder object is of the item class, so it is reasonable to describe this class as abstract. Nevertheless, it's a bit different from BBEdit's item class: in the Finder, some classes have an item element. So you can use the term item when scripting the Finder, in ways that you never would when scripting BBEdit. For example:
tell application "Finder"
class of item 1 of desktop -- document file (not item)
end tell
We come now to the question of how inheritance is portrayed in a dictionary display. In the Script Editor, inheritance is simply stated as a fact. For example, in Figure 20-2, the disk class listing says: "inh. container > item." This means that disk inherits from container, which inherits from item. The implication is that when you look at the disk class listing in Script Editor, you're not being shown all the properties of disk. To see the rest of disk's properties,