-
Notifications
You must be signed in to change notification settings - Fork 292
/
objects.pod6
1301 lines (1040 loc) · 40.7 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 :kind("Language") :subkind("Language") :category("fundamental")
=TITLE Object orientation
=SUBTITLE Object orientation in Raku
Raku provides strong support for L<Object Oriented Programming (OOP)|https://en.wikipedia.org/wiki/Object-oriented_programming>.
Although Raku allows programmers to program in multiple paradigms,
Object Oriented Programming is at the heart of the language.
Raku comes with a wealth of predefined types, which can be classified
in two categories: regular 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 I<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)]»
Similarly, multiple arguments can be specified by placing a colon after
the method and separating the argument list with a comma:
=for code :preamble<my @words;>
say @words.join('--').subst: 'years', 'DAYS';
# OUTPUT: «Abe--Lincoln--said--Fourscore and seven DAYS 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) might 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<=>|/routine/=> operator.
All objects support methods from class L<Mu|/type/Mu>, which is the type
hierarchy root. All objects derive from C<Mu>.
X<|Type objects>
=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 request the type object of anything 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|/type/Mu>) can be compared for equality with the
L<C<===>|/routine/===> 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>|/routine/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.
=for code
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:
=for code
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 Raku, all
attributes are I<private>, which 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.
=begin code
class Journey {
has $!origin;
has $!destination;
has @!travelers;
has $!notes;
}
=end code
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).
=begin code
class Journey {
has $.origin;
has $.destination;
has @!travelers;
has $.notes;
}
=end code
This defaults to providing a read-only accessor. In order to allow changes
to the attribute, add the L<is rw|/routine/is%20rw> trait:
=begin code
class Journey {
has $.origin;
has $.destination;
has @!travelers;
has $.notes is rw;
}
=end code
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|/routine/is%20required> trait.
=begin code
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;
}
=end code
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.
=begin code
my $ⲧ = " " xx 4; # A tab-like thing
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 ⤶
=end code
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.
=begin code
class A { has $.b };
my $name = 'b';
A.new."$name"().say;
# OUTPUT: «(Any)»
=end code
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
Raku 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<explicit invocant> as its first parameter
followed by a colon, which allows for the method to refer to the object
it was called on.
=begin code
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»
=end code
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).
=begin code
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'?»
=end code
A method can be both a class and object method by using the
L<multi|/syntax/multi> declarator:
=begin code
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»
=end code
=head2 X<C<self>>
Inside a method, the term C<self> is available and bound to the invocant
object. C<self> can be used to call further methods on the invocant,
including constructors:
=begin code
class Box {
has $.data;
method make-new-box-from() {
self.new: data => $!data;
}
}
=end code
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:
=begin code
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'?»
=end code
C<self> can also be used with attributes, as long as they have an accessor.
C<self.a> will call the accessor for an attribute declared as C<has $.a>.
However, there is a difference between C<self.a> and C<$.a>, since the latter
will itemize; C<$.a> will be equivalent to C<self.a.item> or C<$(self.a)>.
=begin code
class A {
has Int @.numbers;
has $.x = (1, 2, 3);
method show-diff() { .say for self.x; .say for $.x }
method twice { self.times: 2 }
method thrice { $.times: 3 }
method times($val = 1) { @!numbers.map(* * $val).list }
};
my $obj = A.new(numbers => [1, 2, 3]);
$obj.show-diff; # OUTPUT: «123(1 2 3)»
say $obj.twice; # OUTPUT: «(2 4 6)»
say $obj.thrice; # OUTPUT: «(3 6 9)»
=end code
The colon-syntax for method arguments is supported for method calls
using either C<self> or the shortcut, as illustrated with the methods
C<twice> and C<thrice> in the example above.
Note that if the relevant methods C<bless>, C<CREATE> of L<Mu|/type/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.
X<|Private 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:
=begin code
class FunMath {
has $.value is required;
method !do-subtraction( $num ) {
if $num ~~ Str {
return $!value + (-1 * $num.chars);
}
return $!value + (-1 * $num);
}
method minus( $minuend: $subtrahend ) {
# invoking the private method on the explicit invocant
$minuend!do-subtraction($subtrahend);
}
}
my $five = FunMath.new(value => 5);
say $five.minus(6); # OUTPUT: «-1»
say $five.do-subtraction(6);
CATCH { default { put .^name ~ ":\n" ~ .Str } }
# OUTPUT: «X::Method::NotFound:
# No such method 'do-subtraction' for invocant of type
# 'FunMath'. Did you mean '!do-subtraction'?»
=end code
Private methods are not inherited by subclasses.
X<|Submethods>
=head2 Submethods
Submethods are public methods that will not be 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 would
certainly have to 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|#Object_construction>.
=head2 Inheritance
Classes can have I<parent classes>.
=for code :preamble<class Parent1 {}; class Parent2 {};>
class Child is Parent1 is Parent2 { }
X<|MRO>
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). Raku 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 metaclass:
=for code
say List.^mro; # ((List) (Cool) (Any) (Mu))
If a class does not specify a parent class, L<Any|/type/Any> is assumed
by default. All classes directly or indirectly derive from L<Mu|/type/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<|delegation (trait handles)>
=head2 Delegation
Delegation is a technique whereby a member of an object (the I«delegatee») is
evaluated in the context of another original object (the I«delegator»). In other
words, all method calls on the delegator are I«delegated» to the delegatee.
In Raku, delegation is specified by applying the L«handles|/language/typesystem#trait_handles»
trait to an attribute. The arguments provided to the trait specify the methods
the current object and the delegatee object will have in common. Instead of a
list of method names, a C<Pair> (for renaming), a list of C<Pairs>, a C<Regex>
or a C<Whatever> can be provided.
=begin code
class Book {
has Str $.title;
has Str $.author;
has Str $.language;
has Cool $.publication;
}
class Product {
has Book $.book handles('title', 'author', 'language', year => 'publication');
}
my $book = Book.new:
:title<Dune>,
:author('Frank Herbert'),
:language<English>,
:publication<1965>
;
given Product.new(:$book) {
say .title; # OUTPUT: «Dune»
say .author; # OUTPUT: «Frank Herbert»
say .language; # OUTPUT: «English»
say .year; # OUTPUT: «1965»
}
=end code
In the example above, the class C«Product» defines the attribute C«$.book»
and mark it with the C«handles» trait to specify the methods that will be
forwarded to the class C«Book» whenever they're invoked on an instance
object of the C«Product» class. There are a few things to notice here:
=item We didn't write any methods inside the C«Product» class that we invoked
in its instance object. Instead, we instructed the class to delegate a call to
any those methods to the C«Book» class.
=item We've specified the method names C«title», C«author», and C«language»
as they appear in the C«Book» class. On the other hand, we've renamed
the C«publication» method to C«year» by providing the appropriate C«Pair».
Delegation can be used as an alternative to inheritance by delegating
to the parent class and not inheriting all of its methods. For example, the
following C«Queue» class delegates several methods proper of queues
to the L«Array|/type/Array» class while also providing a preferred interface for
a few of those methods (e.g., C«enqueue» for C«push»):
=begin code
class Queue {
has @!q handles(
enqueue => 'push', dequeue => 'shift',
'push', 'shift', 'head', 'tail', 'elems', 'splice'
);
method gist {
'[' ~ @!q.join(', ') ~ ']'
}
}
my Queue $q .= new;
$q.enqueue($_) for 1..5;
$q.push(6);
say $q.shift; # OUTPUT: «1»
say $q.dequeue while $q.elems; # OUTPUT: «23456»
$q.enqueue($_) for <Perl Python Raku Ruby>;
say $q.head; # OUTPUT: «Perl»
say $q.tail; # OUTPUT: «Ruby»
say $q; # OUTPUT: «[Perl, Python, Raku, Ruby]»
$q.dequeue while $q.elems;
say $q; # OUTPUT: «[]»
=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|/type/Mu> provides a constructor method called
L<new|/routine/new>, which takes named
L<arguments|/language/functions#Arguments> and uses them to initialize public
attributes.
=begin code
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»
=end code
C<Mu.new> calls method L<bless|/routine/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|/type/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 initialized 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> and 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 :preamble<has $!enc; has $!data>
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:
=begin code
class Point {
has $.x;
has $.y;
method new($x, $y) {
self.bless(:$x, :$y);
}
}
=end code
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 Raku. It is
merely a common convention, one that is followed quite thoroughly in
L<most Raku 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 the L<clone|/routine/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|/routine/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>
Roles are a collection of attributes and methods; however, unlike classes, roles
are meant for describing only parts of an object's behavior; this is why, in
general, roles are intended to be I<mixed in> classes and objects. In general,
classes are meant for managing objects and roles are meant for managing behavior
and code reuse within objects.
X<|does>
Roles use the keyword C<role> preceding the name of the role that is
declared. Roles are mixed in using the C<does> keyword preceding the name of
the role that is mixed in.
Roles can also be mixed into a class using C<is>. However, the semantics of
C<is> with a role are quite different from those offered by C<does>. With C<is>,
a class is punned from the role, and then inherited from. Thus, there is no
flattening composition, and none of the safeties which C<does> provides.
=begin code
constant ⲧ = " " xx 4; #Just a ⲧab
role Notable {
has Str $.notes is rw;
multi method notes() { "$!notes\n" };
multi method notes( Str $note ) { $!notes ~= "$note\n" ~ ⲧ };
}
class Journey does Notable {
has $.origin;
has $.destination;
has @.travelers;
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 ⤶
=end code
Roles are immutable as soon as the compiler parses the closing curly brace
of the role declaration.
=head2 Applying roles
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.
=begin code
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)»
=end code
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<illustrates error>
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
=begin code
role R1 {
# methods here
}
role R2 does R1 {
# methods here
}
class C does R2 { }
=end code
produces the same class C<C> as
=begin code
role R1 {
# methods here
}
role R2 {
# methods here
}
class C does R1 does R2 { }
=end code
=head2 Stubs
When a role contains a stubbed method, that is, a method whose code is limited
to C<...>, 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<illustrates error>
role AbstractSerializable {
method serialize() { ... } # literal ... here marks the