Paquetes -- Flash CS3

En ActionScript 3.0 los paquetes se implementan con espacios de nombres, pero son un concepto distinto. Al declarar un paquete, se crea implícitamente un tipo especial de espacio de nombres que se conoce en tiempo de compilación. Si los espacios de nombres se crean explícitamente, no se conocerán necesariamente en tiempo de compilación.

En el ejemplo siguiente se utiliza la directiva package para crear un paquete sencillo que contiene una clase:

package samples
{
    public class SampleCode
    {
        public var sampleGreeting:String;
        public function sampleFunction()
        {
            trace(sampleGreeting + " from sampleFunction()");
        }
    }
}

El nombre de la clase de este ejemplo es SampleCode. Como la clase está en el paquete samples, el compilador califica automáticamente el nombre de la clase en tiempo de compilación con su nombre completo: samples.SampleCode. El compilador también califica los nombres de propiedades y métodos, de forma que sampleGreeting y sampleFunction() se convierten en samples.SampleCode.sampleGreeting y samples.SampleCode.sampleFunction(), respectivamente.

Muchos desarrolladores, especialmente los que tienen experiencia en programación con Java, pueden elegir colocar únicamente clases en el nivel superior de un paquete. Sin embargo, ActionScript 3.0 no sólo admite clases en el nivel superior de un paquete, sino también variables, funciones e incluso sentencias. Un uso avanzado de esta característica consiste en definir un espacio de nombres en el nivel superior de un paquete de forma que esté disponible para todas las clases del paquete. Sin embargo, hay que tener en cuenta que sólo se admiten dos especificadores de acceso, public y internal, en el nivel superior de un paquete. A diferencia de Java, que permite declarar clases anidadas como privadas, ActionScript 3.0 no admite clases anidadas privadas ni anidadas.

Sin embargo, en muchos otros aspectos los paquetes de ActionScript 3.0 son similares a los paquetes del lenguaje de programación Java. Como se puede ver en el ejemplo anterior, las referencias de nombre completo a paquetes se expresan con el operador punto (.), igual que en Java. Se pueden utilizar paquetes para organizar el código en una estructura jerárquica intuitiva que puedan usar otros programadores. Esto permite compartir código fácilmente, ya que ofrece una manera de crear un paquete para compartirlo con otros y de utilizar en el código paquetes creados por otros.

El uso de paquetes también ayuda a garantizar que los nombres de los identificadores utilizados son únicos y no entran en conflicto con otros nombres de identificador. De hecho, se podría decir que ésta es la ventaja principal de los paquetes. Por ejemplo, dos programadores que desean compartir código pueden haber creado una clase denominada SampleCode. Sin los paquetes, esto crearía un conflicto de nombres y la única resolución sería cambiar el nombre de una de las clases. Sin embargo, con los paquetes el conflicto de nombres se evita fácilmente colocando una de las clases (o las dos, preferiblemente) en paquetes con nombres únicos.

También se pueden incluir puntos incorporados en el nombre de paquete para crear paquetes anidados. Esto permite crear una organización jerárquica de paquetes. Un buen ejemplo de esto es el paquete flash.xml proporcionado por la API de Flash Player. El paquete flash.xml está anidado dentro del paquete flash.

El paquete flash.xml contiene el analizador de XML antiguo, que se usaba en versiones anteriores de ActionScript. Una de las razones por las que ahora está en el paquete flash.xml es que hay un conflicto entre el nombre de la clase XML antigua y el nombre de la nueva clase XML que implementa la funcionalidad de la especificación de XML para ECMAScript (E4X) disponible en ActionScript 3.0.

Aunque pasar de la clase XML antigua a un paquete es un buen primer paso, la mayoría de los usuarios de las clases XML antiguas importarán el paquete flash.xml, lo que generará el mismo conflicto de nombres, a menos que recuerden que siempre deben utilizar el nombre completo de la clase XML antigua (flash.xml.XML). Para evitar esta situación, la clase XML antigua ahora se denomina XMLDocument, como se indica en el siguiente ejemplo:

package flash.xml
{
    class XMLDocument {}
    class XMLNode {}
    class XMLSocket {}
}

La mayor parte de la API de Flash Player está organizada bajo el paquete flash. Por ejemplo, el paquete flash.display contiene la API de la lista de visualización y el paquete flash.events contiene el nuevo modelo de eventos.

Creación de paquetes

ActionScript 3.0 proporciona una gran flexibilidad para organizar los paquetes, las clases y los archivos de código fuente. Las versiones anteriores de ActionScript sólo permitían una clase por archivo de código fuente y requerían que el nombre del archivo coincidiera con el nombre de la clase. ActionScript 3.0 permite incluir varias clases en un archivo de código fuente, pero sólo puede estar disponible una clase de cada archivo para el código externo a ese archivo. Es decir, sólo se puede declarar una clase de cada archivo en una declaración de paquete. Hay que declarar las clases adicionales fuera de la definición de paquete, lo que hace que estas clases sean invisibles para el código externo a ese archivo de código fuente. El nombre de clase declarado en la definición de paquete debe coincidir con el nombre del archivo de código fuente.

ActionScript 3.0 también proporciona más flexibilidad para la declaración de paquetes. En versiones anteriores de ActionScript, los paquetes sólo representaban directorios en los que se colocaban archivos de código fuente y no se declaraban con la sentencia package, sino que se incluía el nombre de paquete como parte del nombre completo de clase en la declaración de clase. Aunque los paquetes siguen representando directorios en ActionScript 3.0, pueden contener algo más que clases. En ActionScript 3.0 se utiliza la sentencia package para declarar un paquete, lo que significa que también se pueden declarar variables, funciones y espacios de nombres en el nivel superior de un paquete. Incluso se pueden incluir sentencias ejecutables en el nivel superior de un paquete. Si se declaran variables, funciones o espacios de nombres en el nivel superior de un paquete, los únicos atributos disponibles en ese nivel son public e internal, y sólo una declaración de nivel de paquete por archivo puede utilizar el atributo public, independientemente de que la declaración sea una clase, una variable, una función o un espacio de nombres.

Los paquetes son útiles para organizar el código y para evitar conflictos de nombres. No se debe confundir el concepto de paquete con el concepto de herencia de clases, que no está relacionado con el anterior. Dos clases que residen en el mismo paquete tendrán un espacio de nombres común, pero no estarán necesariamente relacionadas entre sí de ninguna otra manera. Asimismo, un paquete anidado puede no tener ninguna relación semántica con su paquete principal.

Importación de paquetes

Si se desea utilizar una clase que está dentro un paquete, se debe importar el paquete o la clase específica. Esto varía con respecto a ActionScript 2.0, donde la importación de clases era opcional.

Por ejemplo, considérese el ejemplo de la clase SampleCode mencionado antes en este capítulo. Si la clase reside en un paquete denominado samples, hay que utilizar una de las siguientes sentencias de importación antes de utilizar la clase SampleCode:

import samples.SampleCode;

En general, la sentencias import deben ser lo más específicas posible. Si se pretende utilizar la clase SampleCode desde el paquete samples, hay que importar únicamente la clase SampleCode, no todo el paquete al que pertenece. La importación de paquetes completos puede producir conflictos de nombres inesperados.

También se debe colocar el código fuente que define el paquete o la clase en la ruta de clases. La ruta de clases es una lista de rutas de directorio locales definida por el usuario que determina dónde buscará el compilador los paquetes y las clases importados. La ruta de clases se denomina a veces ruta de compilación o ruta de código fuente.

Tras importar correctamente la clase o el paquete, se puede utilizar el nombre completo de la clase (samples.SampleCode) o simplemente el nombre de clase (SampleCode).

Los nombres completos son útiles cuando hay ambigüedad en el código a causa de clases, métodos o propiedades con nombre idénticos, pero pueden ser difíciles de administrar si se usan para todos los identificadores. Por ejemplo, la utilización del nombre completo produce código demasiado extenso al crear una instancia de la clase SampleCode:

var mySample:samples.SampleCode = new samples.SampleCode();

A medida que aumentan los niveles de paquetes anidados, la legibilidad del código disminuye. En las situaciones en las que se esté seguro de que los identificadores ambiguos no constituirán un problema, se puede hacer el código más legible utilizando identificadores sencillos. Por ejemplo, al crear una nueva instancia de la clase SampleCode, el resultado será mucho menos extenso si se utiliza sólo el identificador de clase:

var mySample:SampleCode = new SampleCode();

Si se intenta utilizar nombres de identificador sin importar primero el paquete o la clase apropiados, el compilador no podrá encontrar las definiciones de clase. Por otra parte, si se importa un paquete o una clase, cualquier intento de definir un nombre que entre en conflicto con un nombre importado generará un error.

Cuando se crea un paquete, el especificador de acceso predeterminado para todos los miembros del paquete es internal, lo que significa que, de manera predeterminada, los miembros del paquete sólo estarán visibles para los otros miembros del paquete. Si se desea que una clase esté disponible para código externo al paquete, se debe declarar la clase como public. Por ejemplo, el siguiente paquete contiene dos clases, SampleCode y CodeFormatter:

// Archivo SampleCode.as
package samples
{
    public class SampleCode {}
}

// Archivo CodeFormatter.as
package samples
{
    class CodeFormatter {}
}

La clase SampleCode está visible fuera del paquete porque se ha declarado como una clase public. Sin embargo, la clase CodeFormatter sólo está visible dentro del mismo paquete samples. Si se intenta acceder la clase CodeFormatter fuera del paquete samples, se generará un error, como se indica en el siguiente ejemplo:

import samples.SampleCode;
import samples.CodeFormatter;
var mySample:SampleCode = new SampleCode(); // correcto, clase pública
var myFormatter:CodeFormatter = new CodeFormatter(); // error

Si se desea que ambas clases estén disponibles para código externo al paquete, se deben declarar las dos como public. No se puede aplicar el atributo public a la declaración del paquete.

Los nombres completos son útiles para resolver conflictos de nombres que pueden producirse al utilizar paquetes. Este escenario puede surgir si se importan dos paquetes que definen clases con el mismo identificador. Por ejemplo, considérese el siguiente paquete, que también tiene una clase denominada SampleCode:

package langref.samples
{
    public class SampleCode {}
}

Si se importan ambas clases de la manera siguiente, se producirá un conflicto de nombres al hacer referencia a la clase SampleCode:

import samples.SampleCode;
import langref.samples.SampleCode;
var mySample:SampleCode = new SampleCode(); // conflicto de nombres

El compilador no sabe qué clase SampleCode debe utilizar. Para resolver este conflicto, hay que utilizar el nombre completo de cada clase, de la manera siguiente:

var sample1:samples.SampleCode = new samples.SampleCode();
var sample2:langref.samples.SampleCode = new langref.samples.SampleCode();