Documentation for routine
handles assembled from the following types:
From Type system
multi sub trait_mod:<handles>(Attribute , )
handles applied to an attribute of a class will delegate all calls to the provided method name to the method with the same name of the attribute. The object referenced by the attribute must be initialized. A type constraint for the object that the call is delegated to can be provided.
is A;say C.new(B.new).m(); # OUTPUT: «B::m has been called.␤»
Instead of a method name, a
Pair (for renaming), a list of names or
Regex or a
Whatever can be provided. In the latter case existing methods, both in the class itself and its inheritance chain, will take precedence. If even local
FALLBACKs should be searched, use a
say C.new.m2; # OUTPUT: «A::m2 has been called.␤»say D.new.m1; # OUTPUT: «A::m1 has been called.␤»say E.new.em1; # OUTPUT: «A::m1 has been called.␤»say F.new.m1; # OUTPUT: «A::m1 has been called.␤»say F.new.m2; # OUTPUT: «A::m2 has been called.␤»
method handles(IO::CatHandle: --> Seq)
Returns a Seq containing the currently-active handle, as well as all the remaining source handles produced by calling next-handle. If the invocant has already been fully-consumed, returns an empty Seq.
This method is especially handy when working with IO::ArgFiles, where you want to treat each filehandle separately:
# print at most the first 2 lines of each file in $*ARGFILES:.say for flat .handles.map: *.lines: 2
It is acceptable to call this method multiple times;
.handles.head is a valid idiom for obtaining the currently-active handle. If, between reification of the elements of the returned Seq the handles get switched by some other means, the next element produced by the Seq would be the next handle of the invocant, not the handle that would've been produced if no switching occurred:
(my := 'file1'.IO).spurt: "1a\n1b\n1c";(my := 'file2'.IO).spurt: "2a\n2b\n2c";(my := 'file3'.IO).spurt: "3a\n3b\n3c";my := IO::CatHandle.new: , , ;for .handles# OUTPUT: «(1a 1b)␤(3a 3b)␤»
Likewise, reifying the returned Seq consumes the invocant's source handles and once it is fully reified the invocant becomes fully-consumed.