Overview

Packages

As in Perl 5, packages are the basis of modules and classes. Unlike in Perl 5, modules and classes are declared with separate keywords, but they're still just packages with extra behaviors.

An ordinary package is declared with the package keyword. It can only be used with a block:

    package Bar {...}   # block is in package Bar

A named package declaration can occur as part of an expression, just like named subroutine declarations.

As a special exception, if a braceless package declaration occurs as the first executable statement in a file, then it's taken to mean that the rest of the file is Perl 5 code.

    package Foo;        # the entire file is Perl 5
    ...

This form is illegal in the middle of a Perl 6 file.

Since there are no barewords in Perl 6, package names must be predeclared, or use the sigil-like^T ::PackageName syntax. The :: prefix does not imply top-levelness as it does in Perl 5. (Use ::* for that.)

A bare package declarator declares an our package within the current package (or module, or class, or role, or...). Use * or GLOBAL:: to declare a global package name.

To declare a lexically scoped package, use my package. Package names are always searched for from innermost scopes to outermost. As with an initial ::, the presence of a :: within the name does not imply globalness (unlike in Perl 5). True globals are always in the GLOBAL:: namespace, which has the shortcut * where that is not ambiguous with "real" operators.

The * namespace is not "main". The default namespace for the main program is *Main in Perl 6. All files start out being parsed in the * package, but switch to some other package scope depending on the first declaration. If that first declaration is not a package variant, then the parsing switches to the "*main" package for Perl 5 code and the "*Main" package for Perl 6 code.

Package traits are set using is:

    package Foo is bar {...}

All symbolic links are done with the ::($expr) syntax, which is legal in any variable, package, module, or class name anywhere a ::Ident is legal. The string returned by the expression will be parsed for :: indicating subpackage names. Do not confuse this with the

    Foo::{$key}

syntax that lets you do a lookup in a particular symbol table. In this case, the key is not parsed for ::. It's just a hash lookup.

Autoloading ^T ^T

A package (or any other similar namespace) can control autoloading. However, Perl 5's AUTOLOAD is being superseded by MMD autoloaders that distinguish declaration from definition, but are not restricted to declaring subs. A run-time declarator multisub is declared as:

    multi CANDO ( MyPackage, $type, $name: *%args --> Container)

which stands in for the declaration of a container object within another container object; it is called when anyone is searching for a name in the package (or module, or class), and the name doesn't already exist in the package. (In particular, .can calls CANDO when trying to determine if a class supports a particular method.) The arguments to CANDO include type information on what kind of object is expected in context, or this may be intuited from the name requested. In any case, there may be multiple CANDO routines that are dispatched via MMD:

    multi CANDO ( MyPackage, Item, $name: *%args --> Container)
    multi CANDO ( MyPackage, Array, $name: *%args --> Container)
    multi CANDO ( MyPackage, Hash, $name: *%args --> Container)
    multi CANDO ( MyPackage, Code, $name: *%args --> Container)

The package itself is just passed as the first argument, since it's the container object. Subsequent arguments identify the desired type of the inner container and the "name" or "key" by which the object is to be looked up in the outer container. Such a name does not include its container name, unlike Perl 5's magical $AUTOLOAD variable.

The CANDO is expected to return an inner container object of the proper sort (i.e. a variable, subroutine, or method object), or to a proxy object that can "autovivify" lazily, or undef if that name is not to be considered declared in the namespace in question.

The declaration merely defines the interface to the new object. That object need not be completely defined yet, though the CANDO routine is certainly allowed to define it eagerly, and even install the inner object into the outer container (the symbol table) if it wants to cache the declaration.

At declaration time it might not yet be known whether the inner container object will be used in lvalue or rvalue context; the use of a proxy object can supply either readonly or rw semantics later.

When the package in question is a class, it is also possible to declare real methods or submethods:

    multi method CANDO ($self: Code, $name: *%args --> Container)

    multi submethod CANDO ($self: Item, $name: *%args --> Container)

The method form is inherited by subclasses. Submethods are never inherited but may still do MMD within the class. (Ordinary multisubs are inherited only to the extent allowed by the MMD mechanism.)

When someone tries to actually call or access an undefined object (which may have come from one of the routines above, or might have just been declared with a body of {...}), or might just be a variable declared without an initializer, a different hook is used to define actual behavior at the last moment:

    submethod AUTODEF ($self:) { ... }

(Unlike the CANDO interface, we do not pass the package.)

This routine is passed an uninitialized (or underinitialized) object, and is expected to define or build the object, but not to call it, since the call is already "scheduled" from somewhere else. (Perl 5's goto &$AUTOLOAD is implicit, in other words. But you can hijack the call via the call builtin, in which case the autoloader behaves just like a wrapper--see S06.)

In any case, there is no longer any magical $AUTOLOAD variable. The AUTODEF is a mutator, and thus is not expected to return the object. No name is passed to AUTODEF--in a context where a name is being declared at call time, the name is automatically introduced with CANDO before AUTODEF is called. The outer container, if available, is accessed via $+CONTAINER. In the case of a sub call, the call's unbound ArgList object will be available via $+ARGLIST. $+ARGLIST is a rw variable, and mutations to it will be seen by the eventual "real" call.

If a AUTODEF submethod wishes merely to perform some action without defining $self, that is fine. It needs to signal that desire by use of an explicit "return;" statement.

A AUTODEF submethod is really just a variant of BUILD with no named arguments. As with BUILD, default values for attributes are applied at the end for any attributes not explicitly set. A typical AUTODEF definition might be:

    submethod AUTODEF { self.=BUILD }

or maybe even just:

    our &AUTODEF ::= &BUILD;