Names (or identifiers) are everywhere in Perl programs: variables, functions, packages, classes, and even filehandles. These names all begin with a letter or an underscore and may optionally include any combination of letters, numbers, and underscores. When the utf8 pragma (unicode) is in effect, you may use any valid UTF-8 characters in identifiers. These are all valid Perl identifiers:
These are invalid Perl identifiers:
Names exist primarily for the benefit of the programmer. These rules apply only to literal names which appear as-is in your source code, such as sub fetch_pie or my $waffleiron. Only Perl's parser enforces the rules about identifier names.
Perl's dynamic nature allows you to refer to entities with names generated at runtime or provided as input to a program. These symbolic lookups provide flexibility at the expense of some safety. In particular, invoking functions or methods indirectly or looking up symbols in a namespace lets you bypass Perl's parser.
Doing so can produce confusing code. As Mark Jason Dominus recommends so effectivelyhttp://perl.plover.com/varvarname.html, use a hash (hashes) or nested data structure (nested_data_structures).
Variable names always have a leading sigil (or symbol) which indicates the type of the variable's value. Scalar variables (scalars) use the dollar sign ($) character. Array variables (arrays) use the at sign (@) character. Hash variables (hashes) use the percent sign (%) character:
These sigils provide a visual namespacing for variable names. It's possible--though confusing--to declare multiple variables of the same name with different types:
Again, names exist to help programmers. Perl won't get confused. People reading this code will.
Perl 5's sigils are variant sigils. As context determines how many items you expect from an operation or what type of data you expect to get, so the sigil governs how you manipulate the data of a variable. For example, to access a single element of an array or a hash, you must use the scalar sigil ($):
The parallel with amount context is important. Using a scalar element of an aggregate as an lvalue (the target of an assignment, on the left side of the = character) imposes scalar context (context_philosophy) on the rvalue (the value assigned, on the right side of the = character).
Similarly, accessing multiple elements of a hash or an array--an operation known as slicing--uses the at symbol (@) and imposes list context... even if the list itself has zero or one elements:
The most reliable way to determine the type of a variable--scalar, array, or hash--is to look at the operations performed on it. Scalars support all basic operations, such as string, numeric, and boolean manipulations. Arrays support indexed access through square brackets. Hashes support keyed access through curly brackets.
Perl provides a mechanism to group similar functions and variables into their own unique named spaces--namespaces (packages). A namespace is a collection of one or more names joined by double colons (::), such that DessertShop::IceCream refers to a logical collection of related variables and functions, such as scoop() and pour_hot_fudge().
Within a namespace, you may use the short name of its members. Outside of the namespace, refer to a member using its fully-qualified name, which includes the namespace, as in DessertShop::IceCream::add_sprinkles().
While standard naming rules apply to package names, by convention user-defined packages all start with uppercase letters. The Perl core reserves lowercase package names for core pragmas (pragmas), such as strict and warnings. This is a policy enforced primarily by community guidelines.
Namespaces do not nest in Perl 5. The relationship between DessertShop::IceCream and DessertShop::IceCream::Freezer is only a storage mechanism, with no further implications on the relationships between parent and child or sibling packages. When Perl looks up a symbol in DessertShop::IceCream::Freezer, it looks in the main:: symbol table for a symbol representing the DessertShop:: namespace, then in there for the IceCream:: namespace, and so on. Only a programmer can make logical relationships between entities obvious--by choosing good names and organizing them well.
Hey! The above document had some coding errors, which are explained below:
- Around line 3:
-
A non-empty Z<>
- Around line 53:
-
Deleting unknown formatting code N<>
Deleting unknown formatting code U<>
- Around line 123:
-
Deleting unknown formatting code N<>