This package contains interfaces for various kinds of definitions found in AS and MXML files.

A definition is anything in source code that can be referred to by name: a package, namespace, class, interface, function, getter, setter, parameter, variable, constant, event, style, or effect.

A key part of semantic analysis and code generation consists of determining what each identifier node in an AST refers by resolving it to a definition. This process is called name resolution For example, when you write

    for (var i:int = 0; i < n; i++)
    {
        trace(i);
    }

the first `i` produces a variable definition named "i". The second, third, and fourth `i` get resolved to this definition.

Most definitions live within scopes. A scope can loosely be thought of as representing either an entire file (for a file scope) or a block of code delimited by curly braces (for a package scope, class scope, interface scope, function/getter/setter scope, catch scope, or with scope). Curly braces within some statements, such as those of a `for` loop, do not produce produce scopes, due to the "hoisting" rules of ActionScript.

In addition to being contained in a scope, some definitions contain an inner scope. Therefore a file scope is the root of a hierarchical data structure containing scopes and definitions. (Think of it as the symbol table for the file.) Definitions which are visible to other files are copied into a project scope for cross-file name resolution.

For AS files, the abstract syntax tree is built first and the file scope is built second. The definitions within the file scope are constructed from definition nodes (that is, nodes implementing `IDefinitionNode`) in the AST. For MXML files, a DOM-like representation known as `MXMLData` is built first, the file scope is built second, and the abstract syntax tree is built third. The definitions within the file scope are constructed from the MXML tags of the `MXMLData`.

After being produced, scopes and definitions that are visible to other files are always resident in memory, so that the other files can perform name resolution. (In fact, they persist even after all other files have performed named resolution, in order to support subsequent incremental compilation.) Scopes and definitions that are internal to a particular file need to exist only when the AST for that file is in memory.

The most important interface in this package is `IDefinition` which is the base interface for all definitions. Each specific type of definition has its own sub-interface:

package | `IPackageDefinition`
namespace | `INamespaceDefinition`
class | `IClassDefinition`
interface | `IInterfaceDefinition`
function | `IFunctionDefinition`
getter | `IGetterDefinition`
setter | `ISetterDefinition`
parameter | `IParameterDefinition`
variable | `IVariableDefinition`
constant | `IConstantDefinition`
event | `IEventDefinition`
style | `IStyleDefinition`
effect | `IEffectDefinition`

All definitions have

- a source location;
- an optional ASDoc comment;
- an optional list of metadata annotations;
- a namespace reference indicating its visibility, such as `public`;
- a set of flags indicating modifiers such as `static` or `override`;
- a base, or unqualified, name;
- a type reference (which may be `null` for some types of definitions.

Specific types of definitions of course store additional information. For example, a class definition stores a reference to the class it extends and references to the interfaces that it implements.

Definitions refer to other definitions indirectly, by name, using an `IReference`. See the `references` subpackage for an explanation of this design.