"If you declare an explicit invocant for an Array type using an array 
The invocant may be given a sigil other than the C<$> "item" sigil using the 
same rules as binding variables to class types as described in S02 under "Names 
and Variables".  For example, if the class does the C<Positional> role, it may 
be declared with the C<@> "array" sigil.

Naturally, declaring an explicit invocant for an Array type lets you use it in 
the usual way, such as using it in list context to produce its elements.

The word "self" is described as a keyword and as a function.  Be stronger about 
defining it.  I suggest,
Within the lexical scope of any method, the C<self> keyword behaves as a 
function that returns the invocant in item context.  It is improper to use this 
pseudo-function in any manner other than to call it directly.  In particular, 
an implementation is not required to support taking a Capture to the function.  
Note, however, that you may I<call> it from a closure.

Also note that, as is usual with Perl, the existance of keywords do not 
preclude the use of identifiers with the same name.  Although this is usually 
considerd bad form to make a variable named C<$if>, defining your invocant to 
be C<$self> is not deemed to be in bad taste.  However, defining C<@self> (or 
other sigil forms other than item) could indeed confuse someone reading the 
code, and is discouraged.

Per conversation with Audry, I suggest adding the following before "Private 
methods are...".

Methods, like any other kind of C<sub>, behave as if defined with C<our> by 
default, if no scope modifier is used.  This is described in S06 under "Named 
subroutines".  However, it may be desirable to use the C<our> keyword 
explicitly, as it offers the ability to put the return type before the method 
name, in the C style.

Reply via email to