Scope/Function names and labels: Difference between revisions

m
Fix Perl 6 -> Raku in comments
(Rename Perl 6 -> Raku, alphabetize, minor clean-up)
m (Fix Perl 6 -> Raku in comments)
Line 681:
=={{header|Raku}}==
(formerly Perl 6)
 
First a little hand-wavey exposition. The lines are rather blurry in Perl 6Raku between subroutines, methods, operators and functions. Methods are associated with an object and are inheritable. Subroutines and operators are not. Other than that though there is a lot of overlap. "A function" doesn't really have a specific definition, but is more of a generic term used when talking about code reference type of things.
 
Methods don't have a separate scope from the object they are attached to. If the object is in scope, the method will be.
 
A subroutine is really just another type of object. It has a code reference and has ROUTINE semantics attached to it. The same holds for operators. Operators are really just subroutines with a funny calling convention. That being the case, scoping for subroutines very closely follows scoping rules for any other Perl 6Raku variable type.
 
In general, subroutines are "my" variables by default (if you don't specify, the "my" is implicit), meaning scoping is lexical to the enclosing block and flows inward. A subroutine defined within a block will be visible to everything inside that block, even other blocks within that block. However, any inner block can define its own subroutine with the same name and that will be used in preference to the routine from an outer block. That implies you can easily override / redefine core functions from the Perl 6Raku setting. The setting is the collection of built in functions supplied by Perl 6Raku, typically and somewhat incongruously referred to as "CORE" even though technically it is the outermost scope. ( SKIN? BARK? CRUST? ... oooo! EXOSKELETON! :-) )
 
Alternately, subroutines may be declared as an "our" variable making it a package global, visible anywhere in the packages' namespace. That is somewhat discouraged though as it pollutes the namespace and reduces the granularity of control.
10,327

edits