/
objects.pod6
1095 lines (862 loc) · 36.5 KB
/
objects.pod6
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
=begin pod :tag<perl6>
=TITLE Object orientation
=SUBTITLE Object orientation in Perl 6
Perl 6 provides strong support for L<Object Oriented Programming (OOP)|https://en.wikipedia.org/wiki/Object-oriented_programming>.
Although Perl 6 allows programmers to program in multiple paradigms,
Object Oriented Programming is at the heart of the language.
Perl 6 comes with a wealth of predefined types, which can be classified
in two categories: normal and L<I<native> types|/language/nativetypes>.
Everything that you can store in a variable is either a I<native value>
or an I<object>. That includes literals, types (type objects), code and
containers.
Native types are used for low-level types (like C<uint64>). Even if I<native>
types do not have the same capabilities as objects, if you call methods on them,
they are automatically I<boxed> into normal objects.
Everything that is not a I<native> value is an <object>.
Objects do allow for both L<inheritance|https://en.wikipedia.org/wiki/Object-oriented_programming#Inheritance_and_behavioral_subtyping> and
L<encapsulation|https://en.wikipedia.org/wiki/Object-oriented_programming#Encapsulation>.
=head1 Using objects
To call a method on an object, add a dot, followed by the method name:
=for code
say "abc".uc;
# OUTPUT: «ABC»
This calls the C<uc> method on C<"abc">, which is an object of type
C<Str>. To supply arguments to the method, add arguments inside parentheses
after the method.
=for code
my $formatted-text = "Fourscore and seven years ago...".indent(8);
say $formatted-text;
# OUTPUT: « Fourscore and seven years ago...»
C<$formatted-text> now contains the above text, but indented 8 spaces.
Multiple arguments are separated by commas:
=for code :preamble<my $formatted-text;>
my @words = "Abe", "Lincoln";
@words.push("said", $formatted-text.comb(/\w+/));
say @words;
# OUTPUT: «[Abe Lincoln said (Fourscore and seven years ago)]»
Multiple arguments can be specified by separating the argument list with a colon:
=for code :preamble<my @words;>
say @words.join: '--';
# OUTPUT: «Abe--Lincoln--said--Fourscore--and--seven--years--ago»
Since you have to put a C<:> after the method if you want to pass arguments
without parentheses, a method call without a colon or parentheses is
unambiguously a method call without an argument list:
say 4.log: ; # OUTPUT: «1.38629436111989» ( natural logarithm of 4 )
say 4.log: +2; # OUTPUT: «2» ( base-2 logarithm of 4 )
say 4.log +2; # OUTPUT: «3.38629436111989» ( natural logarithm of 4, plus 2 )
Many operations that don't look like method calls (for example, smartmatching or
interpolating an object into a string) result in method calls under the hood.
Methods can return mutable containers, in which case you can assign to the
return value of a method call. This is how read-writable attributes to
objects are used:
=for code
$*IN.nl-in = "\r\n";
Here, we call method C<nl-in> on the C<$*IN> object, without arguments,
and assign to the container it returned with the L<C<=>|=> operator.
All objects support methods from class L<Mu>, which is the type hierarchy root.
All objects derive from C<Mu>.
=head2 Type objects
Types themselves are objects and you can get the I<type object> by writing its name:
=for code
my $int-type-obj = Int;
You can ask any object for its type object by calling the C<WHAT> method
(which is actually a macro in method form):
=for code :ok-test<WHAT>
my $int-type-obj = 1.WHAT;
Type objects (other than L<Mu>) can be compared for equality with the
L<C<===>|===> identity operator:
=for code :ok-test<WHAT>
sub f(Int $x) {
if $x.WHAT === Int {
say 'you passed an Int';
}
else {
say 'you passed a subtype of Int';
}
}
Although, in most cases, the L<C<.isa>|isa> method will suffice:
=for code
sub f($x) {
if $x.isa(Int) {
...
}
...
}
Subtype checking is done by L<smartmatching|/language/operators#infix_~~>:
=for code :preamble<my $type;>
if $type ~~ Real {
say '$type contains Real or a subtype thereof';
}
=head1 X<Classes|declarator,class>
Classes are declared using the C<class> keyword, typically followed by a
name.
class Journey { }
This declaration results in a type object being created and installed in the
current package and current lexical scope under the name C<Journey>. You
can also declare classes lexically:
my class Journey { }
This restricts their visibility to the current lexical scope, which can be
useful if the class is an implementation detail nested inside a module or
another class.
=head2 Attributes
X<|Attribute> X<|Property> X<|Member> X<|Slot>
Attributes are variables that exist per instance of a class; when instantiated to a value, the association between the variable and its value is called a property. They are where
the state of an object is stored. In Perl 6, all attributes are I<private>,
that means they can be accessed directly only by the class instance itself.
They are typically declared using the C<has> declarator and the C<!> twigil.
class Journey {
has $!origin;
has $!destination;
has @!travelers;
has $!notes;
}
While there is no such thing as a public (or even protected) attribute,
there is a way to have accessor methods generated automatically: replace the
C<!> twigil with the C<.> twigil (the C<.> should remind you of a method
call).
class Journey {
has $.origin;
has $.destination;
has @!travelers;
has $.notes;
}
This defaults to providing a read-only accessor. In order to allow changes
to the attribute, add the L<is rw> trait:
class Journey {
has $.origin;
has $.destination;
has @!travelers;
has $.notes is rw;
}
Now, after a C<Journey> object is created, its C<.origin>, C<.destination>,
and C<.notes> will all be accessible from outside the class, but only
C<.notes> can be modified.
If an object is instantiated without certain attributes, such as origin or
destination, we may not get the desired result. To prevent this, provide
default values or make sure that an attribute is set on object creation
by marking an attribute with an L<is required> trait.
class Journey {
# error if origin is not provided
has $.origin is required;
# set the destination to Orlando as default (unless that is the origin!)
has $.destination = self.origin eq 'Orlando' ?? 'Kampala' !! 'Orlando';
has @!travelers;
has $.notes is rw;
}
Since classes inherit a default constructor from C<Mu> and we have requested
that some accessor methods are generated for us, our class is already
somewhat functional.
=begin code :preamble<class Journey {};>
# Create a new instance of the class.
my $vacation = Journey.new(
origin => 'Sweden',
destination => 'Switzerland',
notes => 'Pack hiking gear!'
);
# Use an accessor; this outputs Sweden.
say $vacation.origin;
# Use an rw accessor to change the value.
$vacation.notes = 'Pack hiking gear and sunglasses!';
=end code
Note that, although the default constructor can initialize read-only
attributes, it will only set attributes that have an accessor method.
That is, even if you pass C«travelers => ["Alex", "Betty"]» to the
default constructor, the attribute C<@!travelers> is not initialized.
=head2 Methods
Methods are declared with the C<method> keyword inside a class body.
=begin code
class Journey {
has $.origin;
has $.destination;
has @!travelers;
has $.notes is rw;
method add-traveler($name) {
if $name ne any(@!travelers) {
push @!travelers, $name;
}
else {
warn "$name is already going on the journey!";
}
}
method describe() {
"From $!origin to $!destination"
}
}
=end code
A method can have a signature, just like a subroutine. Attributes can be
used in methods and can always be used with the C<!> twigil, even if they
are declared with the C<.> twigil. This is because the C<.> twigil
declares a C<!> twigil and generates an accessor method.
Looking at the code above,
there is a subtle but important difference between using C<$!origin>
and C<$.origin> in the method C<describe>.
C<$!origin> is an inexpensive and obvious lookup of the attribute.
C<$.origin> is a method call and thus may be overridden in a subclass.
Only use C<$.origin> if you want to allow overriding.
Unlike subroutines, additional named arguments will not produce compile time or
runtime errors. That allows chaining of methods via
L<Re-dispatching|/language/functions#Re-dispatching>.
You may write your own accessors to override any or all of the autogenerated ones.
my $ⲧ = " " xx 4;
class Journey {
has $.origin;
has $.destination;
has @.travelers;
has Str $.notes is rw;
multi method notes() { "$!notes\n" };
multi method notes( Str $note ) { $!notes ~= "$note\n$ⲧ" };
method Str { "⤷ $!origin\n$ⲧ" ~ self.notes() ~ "$!destination ⤶\n" };
}
my $trip = Journey.new( :origin<Here>, :destination<There>,
travelers => <þor Freya> );
$trip.notes("First steps");
notes $trip: "Almost there";
print $trip;
# OUTPUT:
#⤷ Here
# First steps
# Almost there
#
#There ⤶
The declared multi method C<notes> overrides the auto-generated
methods implicit in the declaration of C<$.notes>, using a different
signature for reading and writing.
Please note that in C<notes $trip: "Almost there"> we are using X<indirect
invocant syntax>, which puts first the method name, then the object, and then,
separated by a colon, the arguments: C<method invocant: arguments>. We can use
this syntax whenever it feels more natural than the classical
period-and-parentheses one. It works exactly in the same way.
Method names can be resolved at runtime with the C<.""> operator.
class A { has $.b };
my $name = 'b';
A.new."$name"().say;
# OUTPUT: «(Any)»
The syntax used to update C<$.notes> changed in this section with respect
to the previous L<#Attributes> section. Instead of an assignment:
=for code :preamble<my $vacation>
$vacation.notes = 'Pack hiking gear and sunglasses!';
we now do a method call:
=for code :preamble<my $trip>
$trip.notes("First steps");
Overriding the default auto-generated accessor means it is no longer
available to provide a mutable container on return for an assignment.
A method call is the preferred approach to adding computation and
logic to the update of an attribute. Many modern languages can update
an attribute by overloading assignment with a “setter” method. While
Perl 6 can overload the assignment operator for this purpose with a
L<C<Proxy>|https://github.com/perl6/roast/blob/master/S12-attributes/mutators.t>
object, overloading assignment to set attributes with complex logic is
currently discouraged as
L<weaker object oriented design|https://6guts.wordpress.com/2016/11/25/perl-6-is-biased-towards-mutators-being-really-simple-thats-a-good-thing/>.
=head2 Class and instance methods
A method's signature can have an I<invocant> as its first parameter
followed by a colon, which allows for the method to refer to the object
it was called on.
class Foo {
method greet($me: $person) {
say "Hi, I am $me.^name(), nice to meet you, $person";
}
}
Foo.new.greet("Bob"); # OUTPUT: «Hi, I am Foo, nice to meet you, Bob»
Providing an invocant in the method signature also allows for defining
the method as either as a class method, or as an object method, through
the use of L<type constraints|/type/Signature#Type_constraints>. The
C<::?CLASS> variable can be used to provide the class name at compile
time, combined with either C<:U> (for class methods) or C<:D> (for
instance methods).
class Pizza {
has $!radius = 42;
has @.ingredients;
# class method: construct from a list of ingredients
method from-ingredients(::?CLASS:U $pizza: @ingredients) {
$pizza.new( ingredients => @ingredients );
}
# instance method
method get-radius(::?CLASS:D:) { $!radius }
}
my $p = Pizza.from-ingredients: <cheese pepperoni vegetables>;
say $p.ingredients; # OUTPUT: «[cheese pepperoni vegetables]»
say $p.get-radius; # OUTPUT: «42»
say Pizza.get-radius; # This will fail.
CATCH { default { put .^name ~ ":\n" ~ .Str } };
# OUTPUT: «X::Parameter::InvalidConcreteness:
# Invocant of method 'get-radius' must be
# an object instance of type 'Pizza',
# not a type object of type 'Pizza'.
# Did you forget a '.new'?»
A method can be both a class and object method by using the
L<multi|/syntax/multi> declarator:
class C {
multi method f(::?CLASS:U:) { say "class method" }
multi method f(::?CLASS:D:) { say "object method" }
}
C.f; # OUTPUT: «class method»
C.new.f; # OUTPUT: «object method»
=head2 self
Inside a method, the term C<self> is available, which is bound to the
invocant. C<self> can be used to call further methods on the invocant,
including constructors:
class Box {
has $.data;
method make-new-box-from() {
self.new: data => $!data;
}
}
C<self> can be used in class or instance methods as well, though beware
of trying to invoke one type of method from the other:
class C {
method g() { 42 }
method f(::?CLASS:U:) { self.g }
method d(::?CLASS:D:) { self.f }
}
C.f; # OUTPUT: «42»
C.new.d; # This will fail.
CATCH { default { put .^name ~ ":\n" ~ .Str } };
# OUTPUT: «X::Parameter::InvalidConcreteness:
# Invocant of method 'f' must be a type object of type 'C',
# not an object instance of type 'C'. Did you forget a 'multi'?»
Within methods, C<$.origin> works the same as C<self.origin>, however
the colon-syntax for method arguments is only supported for method calls
using C<self>, not the shortcut.
Note that if the relevant methods C<bless>, C<CREATE> of L<Mu>
are not overloaded, C<self> will point to the type object in those methods.
On the other hand, the submethods C<BUILD> and C<TWEAK> are
called on instances, in different stages of initialization. Submethods of the
same name from subclasses have not yet run, so
you should not rely on potentially virtual method calls inside these methods.
=head2 Private methods
Methods with an exclamation mark C<!> before the method name are not callable
from anywhere outside the defining class; such methods are private in the sense
that they are not visible from outside the class that declares them. Private
methods are invoked with an exclamation mark instead of a dot:
method !do-something-private($x) {
...
}
method public($x) {
if self.precondition {
self!do-something-private(2 * $x)
}
}
Private methods are not inherited by subclasses.
=head2 Submethods
Submethods are public methods that are not inherited by subclasses. The name
stems from the fact that they are semantically similar to subroutines.
Submethods are useful for object construction and destruction tasks, as well
as for tasks that are so specific to a certain type that subtypes must
certainly override them.
For example, the L<default method new|/type/Mu#method_new> calls submethod
C<BUILD> on each class in an L<inheritance|#Inheritance> chain:
=begin code
class Point2D {
has $.x;
has $.y;
submethod BUILD(:$!x, :$!y) {
say "Initializing Point2D";
}
}
class InvertiblePoint2D is Point2D {
submethod BUILD() {
say "Initializing InvertiblePoint2D";
}
method invert {
self.new(x => - $.x, y => - $.y);
}
}
say InvertiblePoint2D.new(x => 1, y => 2);
# OUTPUT: «Initializing Point2D»
# OUTPUT: «Initializing InvertiblePoint2D»
# OUTPUT: «InvertiblePoint2D.new(x => 1, y => 2)»
=end code
See also: L<#Object_construction>.
=head2 Inheritance
Classes can have I<parent classes>.
=for code :preamble<class Parent1 {}; class Parent2 {};>
class Child is Parent1 is Parent2 { }
If a method is called on the child class, and the child class does not
provide that method, the method of that name in one of the parent classes is
invoked instead, if it exists. The order in which parent classes are
consulted is called the I<method resolution order> (MRO). Perl 6 uses the
L<C3 method resolution order|https://en.wikipedia.org/wiki/C3_linearization>.
You can ask a type for its MRO through a call to its meta class:
say List.^mro; # ((List) (Cool) (Any) (Mu))
If a class does not specify a parent class, L<Any> is assumed by default.
All classes directly or indirectly derive from L<Mu>, the root of the type
hierarchy.
All calls to public methods are "virtual" in the C++ sense, which means that
the actual type of an object determines which method to call, not the
declared type:
=begin code
class Parent {
method frob {
say "the parent class frobs"
}
}
class Child is Parent {
method frob {
say "the child's somewhat more fancy frob is called"
}
}
my Parent $test;
$test = Child.new;
$test.frob; # calls the frob method of Child rather than Parent
# OUTPUT: «the child's somewhat more fancy frob is called»
=end code
X<|new (method)>
=head2 Object construction
Objects are generally created through method calls, either on the type
object or on another object of the same type.
Class L<Mu> provides a constructor method called L<new>, which takes named
L<arguments|/language/functions#Arguments> and uses them to initialize public attributes.
class Point {
has $.x;
has $.y;
}
my $p = Point.new( x => 5, y => 2);
# ^^^ inherited from class Mu
say "x: ", $p.x;
say "y: ", $p.y;
# OUTPUT: «x: 5»
# OUTPUT: «y: 2»
C<Mu.new> calls method L<bless> on its invocant, passing all the named
L<arguments|/language/functions#Arguments>. C<bless> creates the new
object, and then walks all subclasses in reverse method resolution order
(i.e. from L<Mu> to most derived classes) and in each class checks for
the existence of a method named C<BUILD>. If the method exists, the
method is called with all the named arguments from the C<new> method. If
not, the public attributes from this class are initialized from named
arguments of the same name. In either case, if neither C<BUILD> nor the
default mechanism has initialized the attribute, default values are
applied. This means that C<BUILD> may change an attribute, but it does
not have access to the contents of the attribute declared as its
default; these are available only during C<TWEAK> (see below), which can
'see' the contents of an attribute initialised in the declaration of the
class.
X<|TWEAK>
After the C<BUILD> methods have been called, methods named C<TWEAK> are
called, if they exist, again with all the named arguments that were passed
to C<new>. See an example of its use below.
Due to the default behavior of C<BUILD> annd C<TWEAK> submethods, named
arguments to the constructor C<new> derived from C<Mu> can
correspond directly to public attributes of any of the classes in the method
resolution order, or to any named parameter of any C<BUILD> or C<TWEAK>
submethod.
This object construction scheme has several implications for customized
constructors. First, custom C<BUILD> methods should always be submethods,
otherwise they break attribute initialization in subclasses. Second,
C<BUILD> submethods can be used to run custom code at object construction
time. They can also be used for creating aliases for attribute
initialization:
=begin code
class EncodedBuffer {
has $.enc;
has $.data;
submethod BUILD(:encoding(:$enc), :$data) {
$!enc := $enc;
$!data := $data;
}
}
my $b1 = EncodedBuffer.new( encoding => 'UTF-8', data => [64, 65] );
my $b2 = EncodedBuffer.new( enc => 'UTF-8', data => [64, 65] );
# both enc and encoding are allowed now
=end code
Since passing arguments to a routine binds the arguments to the parameters,
a separate binding step is unnecessary if the attribute is used as a
parameter. Hence the example above could also have been written as:
=begin code :skip-test
submethod BUILD(:encoding(:$!enc), :$!data) {
# nothing to do here anymore, the signature binding
# does all the work for us.
}
=end code
However, be careful when using this auto-binding of attributes
when the attribute may have special type requirements, such as an C<:$!id>
that must be a positive integer. Remember, default values will be assigned
unless you specifically take care of this attribute, and that
default value will be C<Any>, which would cause a type error.
The third implication is that if you want a constructor that accepts
positional arguments, you must write your own C<new> method:
class Point {
has $.x;
has $.y;
method new($x, $y) {
self.bless(:$x, :$y);
}
}
However this is considered poor practice, because it makes correct
initialization of objects from subclasses harder.
Another thing to note is that the name C<new> is not special in Perl 6. It is
merely a common convention, one that is followed quite thoroughly in L<most Perl 6
classes|/routine/new>. You can call C<bless> from any method at all, or use
C<CREATE> to fiddle around with low-level workings.
The C<TWEAK> submethod allows you to check things or modify attributes after
object construction:
=begin code
class RectangleWithCachedArea {
has ($.x1, $.x2, $.y1, $.y2);
has $.area;
submethod TWEAK() {
$!area = abs( ($!x2 - $!x1) * ( $!y2 - $!y1) );
}
}
say RectangleWithCachedArea.new( x2 => 5, x1 => 1, y2 => 1, y1 => 0).area;
# OUTPUT: «4»
=end code
=head2 Object cloning
The cloning is done using L<clone> method available on all objects, which
shallow-clones both public and private attributes. New values for I<public>
attributes can be supplied as named arguments.
=begin code
class Foo {
has $.foo = 42;
has $.bar = 100;
}
my $o1 = Foo.new;
my $o2 = $o1.clone: :bar(5000);
say $o1; # Foo.new(foo => 42, bar => 100)
say $o2; # Foo.new(foo => 42, bar => 5000)
=end code
See document for L<clone> for details on how non-scalar attributes get cloned,
as well as examples of implementing your own custom clone methods.
=head1 X<Roles|declarator,role>
X<|does>
Roles are in some ways similar to classes, in that they are a collection of
attributes and methods. They differ in that roles are also meant for
describing only parts of an object's behavior and in how roles are applied
to classes. Or to phrase it differently, classes are meant for managing
objects and roles are meant for managing behavior and code reuse.
=begin code
use MONKEY-SEE-NO-EVAL;
role Serializable {
method serialize() {
self.perl; # very primitive serialization
}
method deserialize($buf) {
EVAL $buf; # reverse operation to .perl
}
}
class Point does Serializable {
has $.x;
has $.y;
}
my $p = Point.new(:x(1), :y(2));
my $serialized = $p.serialize;
my $clone-of-p = Point.deserialize($serialized);
say $clone-of-p.x; # OUTPUT: «1»
=end code
Roles are immutable as soon as the compiler parses the closing curly brace of
the role declaration.
=head2 Application of role
Role application differs significantly from class inheritance. When a role
is applied to a class, the methods of that role are copied into the class.
If multiple roles are applied to the same class, conflicts (e.g.
attributes or non-multi methods of the same name) cause a compile-time error,
which can be solved by providing a method of the same name in the class.
This is much safer than multiple inheritance, where conflicts are never
detected by the compiler, but are instead resolved to the superclass
that appears earlier in the method resolution order, which might not
be what the programmer wanted.
For example, if you've discovered an efficient method to ride cows, and are
trying to market it as a new form of popular transportation, you might have
a class C<Bull>, for all the bulls you keep around the house, and a class
C<Automobile>, for things that you can drive.
class Bull {
has Bool $.castrated = False;
method steer {
# Turn your bull into a steer
$!castrated = True;
return self;
}
}
class Automobile {
has $.direction;
method steer($!direction) { }
}
class Taurus is Bull is Automobile { }
my $t = Taurus.new;
say $t.steer;
# OUTPUT: «Taurus.new(castrated => Bool::True, direction => Any)»
With this setup, your poor customers will find themselves unable to turn
their Taurus and you won't be able to make more of your product! In this
case, it may have been better to use roles:
=begin code :skip-test
role Bull-Like {
has Bool $.castrated = False;
method steer {
# Turn your bull into a steer
$!castrated = True;
return self;
}
}
role Steerable {
has Real $.direction;
method steer(Real $d = 0) {
$!direction += $d;
}
}
class Taurus does Bull-Like does Steerable { }
=end code
This code will die with something like:
=begin code :lang<text>
===SORRY!===
Method 'steer' must be resolved by class Taurus because it exists in
multiple roles (Steerable, Bull-Like)
=end code
This check will save you a lot of headaches:
=begin code :preamble<role Bull-Like{}; role Steerable{};>
class Taurus does Bull-Like does Steerable {
method steer($direction?) {
self.Steerable::steer($direction)
}
}
=end code
When a role is applied to a second role, the actual application is delayed
until the second role is applied to a class, at which point both roles are
applied to the class. Thus
role R1 {
# methods here
}
role R2 does R1 {
# methods here
}
class C does R2 { }
produces the same class C<C> as
role R1 {
# methods here
}
role R2 {
# methods here
}
class C does R1 does R2 { }
=head2 Stubs
When a role contains a L<stubbed|/routine/...> method,
a non-stubbed version of a method of the same name must be supplied
at the time the role is applied to a class. This allows you to
create roles that act as abstract interfaces.
=begin code :skip-test
role AbstractSerializable {
method serialize() { ... } # literal ... here marks the
# method as a stub
}
# the following is a compile time error, for example
# Method 'serialize' must be implemented by Point because
# it's required by a role
class APoint does AbstractSerializable {
has $.x;
has $.y;
}
# this works:
class SPoint does AbstractSerializable {
has $.x;
has $.y;
method serialize() { "p($.x, $.y)" }
}
=end code
The implementation of the stubbed method may also be provided by another
role.
=head2 Inheritance
Roles cannot inherit from classes, but they may I<carry> classes, causing
any class which does that role to inherit from the carried classes.
So if you write:
=begin code
role A is Exception { }
class X::Ouch does A { }
X::Ouch.^parents.say # OUTPUT: «((Exception))»
=end code
then C<X::Ouch> will inherit directly from Exception, as we can see above
by listing its parents.
As they do not use what can properly be called inheritance, roles are not part of the class hierarchy.
Roles are listed with the C<.^roles> meta-method instead, which uses C<transitive> as flag for including all levels or just the first one. Despite this, a
class or instance may still be tested with smartmatches or type constraints
to see if it does a role.
=begin code
role F { }
class G does F { }
G.^roles.say; # OUTPUT: «((F))»
role Ur {}
role Ar does Ur {}
class Whim does Ar {}; Whim.^roles(:!transitive).say; # OUTPUT: «((Ar))»
say G ~~ F; # OUTPUT: «True»
multi a (F $a) { "F".say }
multi a ($a) { "not F".say }
a(G); # OUTPUT: «F»
=end code
=head2 Pecking order
A method defined directly in a class will always override definitions from
applied roles or from inherited classes. If no such definition exists, methods
from roles override methods inherited from classes. This happens both when
said class was brought in by a role, and also when said class was inherited
directly.
role M {
method f { say "I am in role M" }
}
class A {
method f { say "I am in class A" }
}
class B is A does M {
method f { say "I am in class B" }
}
class C is A does M { }
B.new.f; # OUTPUT «I am in class B»
C.new.f; # OUTPUT «I am in role M»
Note that each candidate for a multi-method is its own method. In this case,
the above only applies if two such candidates have the same signature.
Otherwise, there is no conflict, and the candidate is just added to the
multi-method.
=head2 Automatic role punning
Any attempt to directly instantiate a role or use it as a type object
will automatically create a class with the same name as the role,
making it possible to transparently use a role as if it were a class.
=begin code
role Point {
has $.x;
has $.y;
method abs { sqrt($.x * $.x + $.y * $.y) }
method dimensions { 2 }
}
say Point.new(x => 6, y => 8).abs; # OUTPUT «10»
say Point.dimensions; # OUTPUT «2»
=end code
We call this automatic creation of classes I<punning>, and the generated class
a I<pun>.
Punning is not caused by most L<meta-programming|/language/mop> constructs,
however, as those are sometimes used to work directly with roles.
X<|Parameterized Roles>
=head2 Parameterized roles
Roles can be parameterized, by giving them a signature in square brackets:
=begin code
role BinaryTree[::Type] {
has BinaryTree[Type] $.left;
has BinaryTree[Type] $.right;
has Type $.node;
method visit-preorder(&cb) {
cb $.node;
for $.left, $.right -> $branch {
$branch.visit-preorder(&cb) if defined $branch;
}
}
method visit-postorder(&cb) {
for $.left, $.right -> $branch {
$branch.visit-postorder(&cb) if defined $branch;
}
cb $.node;
}
method new-from-list(::?CLASS:U: *@el) {
my $middle-index = @el.elems div 2;
my @left = @el[0 .. $middle-index - 1];
my $middle = @el[$middle-index];
my @right = @el[$middle-index + 1 .. *];
self.new(
node => $middle,
left => @left ?? self.new-from-list(@left) !! self,
right => @right ?? self.new-from-list(@right) !! self,
);
}
}
my $t = BinaryTree[Int].new-from-list(4, 5, 6);
$t.visit-preorder(&say); # OUTPUT: «546»
$t.visit-postorder(&say); # OUTPUT: «465»
=end code
Here the signature consists only of a type capture, but any signature will do:
=begin code
enum Severity <debug info warn error critical>;
role Logging[$filehandle = $*ERR] {
method log(Severity $sev, $message) {
$filehandle.print("[{uc $sev}] $message\n");
}
}
Logging[$*OUT].log(debug, 'here we go'); # OUTPUT: «[DEBUG] here we go»
=end code
You can have multiple roles of the same name, but with different signatures;
the normal rules of multi dispatch apply for choosing multi candidates.
X<|but>
=head2 X<Mixins> of roles
Roles can be mixed into objects. A role's given attributes and methods will be
added to the methods and attributes the object already has. Multiple mixins and
anonymous roles are supported.
role R { method Str() {'hidden!'} };
my $i = 2 but R;
sub f(\bound){ put bound };
f($i); # OUTPUT: «hidden!»
my @positional := <a b> but R;
say @positional.^name; # OUTPUT: «List+{R}»
Note that the object got the role mixed in, not the object's class or the
container. Thus, @-sigiled containers will require binding to make the role
stick as is shown in the example with C<@positional>. Some operators will return
a new value, which effectively strips the mixin from the result. That is why it
might be more clear to mix in the role in the declaration of the variable using
C<does>:
role R {};
my @positional does R = <a b>;
say @positional.^name; # OUTPUT: «Array+{R}»