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
forloop, which will respect lazinessfor self.list { ... }If you assemble multiple items into a potentially lazy list,
gather/takeis 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
SETTINGvariable and re-generate the Makefile using Configure.pl. - Prefer
selfto 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
@valueswill restrict the method to invocants that have thePositionalrole). Better is to useself, or if invoking a method onselfthen you can use$.fooor@.bardirectly. - 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
returnstatement is executed in a routine, the value of the last evaluated expression is returned.So if a
return EXPRis the last statement in a routine, omit thereturn- currently explicit returns take much more time than implicit ones.