Guide to the src/core
setting.
Notes about writing code to go in Rakudo's setting.
- Think of laziness
-
Avoid anything that forces eager evaluation of arrays, like querying their length.
This is bad:
while $i < self.elems { ... }
Better use a
for
loop, which will respect lazinessfor self.list { ... }
If you assemble multiple items into a potentially lazy list,
gather/take
is a very good construct to remember. - Take care with type constraints
-
Some of the Synopsis documents list type constraints for some of the arguments, including the invocant. They are not always correct, when in doubt leave them out.
- When adding a new file in src/core/
-
... remember to add it to "Makefile.in" in build to the
SETTING
variable and re-generate the Makefile using Configure.pl. - Prefer
self
to explicit invocant variables. -
Many of the method specifications in the synopses list explicit invocant variables. Using them often makes the code less clear, and can sometimes be incorrect (for example, an invocant of
@values
will restrict the method to invocants that have thePositional
role). Better is to useself
, or if invoking a method onself
then you can use$.foo
or@.bar
directly. - All subs and methods are really multis
-
All built-in methods or subroutines should be declared as
multi
. - Use explicit empty signatures
-
If a method doesn't take any arguments, give it an explicit empty signature
()
. That's very different from omitting the signature altogether (which would be an implicit catch-all signature). - Use implicit return at the end of routines
-
If no
return
statement is executed in a routine, the value of the last evaluated expression is returned.So if a
return EXPR
is the last statement in a routine, omit thereturn
- currently explicit returns take much more time than implicit ones.