Curso Applescript: Clases: propiedades, elementos, superclases y subclases, por Julifos

En AppleScript, tenemos básicamente dos cosas (muy básicamente, se entiende): los comandos y las clases, que también podríamos llamar objetos.

Un ejemplo de comando podría ser, en carpintería, “clavar”. Un parámetro, perteneciente al comando, un “clavo”. Y una clase, una “mesa”. Las clases son algo así como los objetos manipulados por los comandos, y objeto de ellos. Una mesa sería objeto de todo tipo de manipulaciones, como “clavarle un clavo”, “sentarse encima de ella” o “utilizarla para apoyar platos con comida”.

Las clases, a su vez, pueden poseer (y suelen hacerlo) propiedades. En el ejemplo de la mesa, puede ser más “alta” o tener un “color” y una “forma”. Algunas de esas propiedades son de “sólo lectura” (o read-only), lo que significa que sólo existen y punto. Y otras que son de “lectura-escritura” (o read-write), que se pueden modificar. Por ejemplo, podríamos tener una clase ficticia que fuese la “mesa-camilla”. Podría tener una absurda propiedad de “sólo lectura” que fuese la “forma”: redonda. Y muchas otras que se pudiesen modificar: la altura, color, el radio…

También, no se vaya vd. a creer, las clases tienen elementos y superclases. Que viene a ser algo así como “hijos” y “padres”. Como uno mismo, vamos. Un ejemplo de “elemento” de una mesa-camilla podría ser un clavo, un tapete, o el mantel. Éstos serían “elementos” que pertenecen al objeto “mesa-camilla”. Cosas que no son atributos de la mesa-camilla (como el color o el tamaño), pero que forman parte de ella y le “pertenecen”. Y un ejemplo de “superclase” (o “padre”) de una mesa-camilla podría ser una “habitación”: el objeto al que pertenece la propia mesa-camilla; al igual que la mesa-camilla podría ser el “superclase” (super class, o “clase por encima”) del mantel, y el mantel el “superclase” del hilo (o plástico, con estos tiempos que corren).

Para rizar más el rizo, también tenemos subclases. Sí, sí… Subclases. Las subclases son cosas iguales, pero ligeramente distintas. Por ejemplo, una subclase de la mesa-camilla podría ser la mesa-camilla-extremeña o (si me apuráis) la mesa-camilla-cantarina. Estas subclases suelen poseer los mismos elementos, superclases y propiedades de su clases (el jefe, la mesa-camilla), pero con ciertas peculiaridades. Por ejemplo, la mesa-camilla-extremeña será igual que una mesa-camilla, pero su propiedad “olor” será siempre “jabugo”, y además no podrá contener comensales “gallegos”, sino sólo “extremeños”. Y la mesa-camilla-cantarina sólo podrá… (bla, bla, bla). Creo que está más o menos claro.

ejemplos

Dado que estamos explicando algunos conceptos un poco absurdos y, a la vez, lógicos, creo que lo mejor es utilizar ejemplos aislados de cada cosa, para que se vea de qué va el percal. Rescatando las subclases, que es lo último de lo que hemos hablado, vamos a ver un ejemplito con objetos (classes) de Entourage, que es un cliente de correo con un diccionario muy completo.

Class message

Sub classes

incoming message, outgoing message

Tenemos una “clase” (u objeto) dentro de la aplicación Entourage, que es un “mensaje”. Aunque no esté expresamente declarado, el mensaje sería una subclase, a su vez de la clase “aplicación” (application), que sería el rey del corral dentro del diccionario.

Esta clase contiene dos subclases: mensaje entrante y mensaje saliente. Como podemos adivinar, los “mensajes salientes” (outgoing messages), tienen algunas propiedades más que los “entrantes”: codificación (que no tiene por qué existir en un mensaje entrante), estado del mensaje (enviado, aún sin enviar, que tampoco puede ser una propiedad lógica del mensaje “entrante”), etc.

Por eso son subclases de la clase “mensaje”: poseen sus propiedades básicas, pero difieren en algunos aspectos (no tantos como para formar una clase completamente distinta).

Ya que estamos con las propiedades, vamos a poner un ejemplo reducido con el mismo “mensaje”:

Class message

Properties

sender

Aquí listamos tres propiedades de muestra del objeto “mensaje”: el asunto (subject), la prioridad (priority) y el remitente (sender). Creo que esto es lo más sencillo de todo, así que pasemos a lo siguiente: los elementos. Siguiendo con el “mensaje”, podemos ver que tiene varios elementos. Entre ellos:

Class message

Elements

¿Y por qué el “attachment” es un elemento, y no una “propiedad”? En este ejemplo concreto, el diccionario de Entourage, un attachment (un archivo adjunto) no es una propiedad porque tiene ciertas características o propiedades, a su vez. No es como un color, que es rojo o es verde, sino que se compone de varios atributos. Concretamente: nombre, codificación, archivo, creador, tipo… Si observamos la clase (subclase del message) attachment, podemos ver que contiene dichas propiedades. Sin embargo, en el caso de la prioridad (priority) no había ninguna propiedad. O la prioridad era “alta” o era “baja” o era “nosecuántos”. Pero no existían más propiedades dentro de la prioridad (no tiene nombre ni anchura ni ná).

Por último, no tenemos superclases dentro del diccionario del Entourage. No porque no las haya, sino porque están sin definir. Cada diccionario es un mundo, y la constatación de la existencia de una superclase tampoco aporta nada, realmente, aparte de organización. Pero en el caso de los attachments, sí se podría decir que la superclase del “archivo adjunto” es el “mensaje”. Simplemente, está sin constatar.

Acudamos ahora al diccionario del Finder. Si lo abrimos, y observamos la suite “Files” (que sólo contiene clases, por organizar de alguna manera) y vemos la clase file, podemos ver:

Class file

Super classes

item

El elemento que, en cierto modo, es el “padre” de un file (o “archivo”) es un item. En el Finder podemos decir, por ejemplo, “first item of desktop”. Y eso hace referencia a un archivo normal con datos (documento de texto, etc.) o a un container (algo que tiene cosas dentro, típicamente una carpeta -folder, disk – o un paquete -package-; vamos, un directorio que contiene cosas). O sea, que una carpeta y un documento de texto son un item (al igual que un hombre y una mujer son un ser humano o persona).

Por último…

Por último, las propiedades pueden hacer referencia a otras clases. Sí, sí… Para no alargarnos mucho: un mensaje tiene la propiedad “remitente”. Y la propiedad remitente no es “negro” ni “rojo” (o true o false, algo concreto), sino que es una “dirección” (address), que es a su vez un objeto que posee sus propiedades: nombre (display name) y dirección (address); que a su vez puede tener sus subclases (o no, pero en este caso sí).

Concretamente en esta situación, yo hubiese definido la propiedad sender (el remitente) como un elemento, ya que es una clase y posee sus propiedades (como podría ser el mantel, que es colorado y muy grande); pero el diseñador del diccionario prefirió que fuese una propiedad. Pues vale, ¿no?

Los restantes artículos sobe AppleScript se pueden encontrar en la categoría de Tutorial