fix improper code blocks, X<...> formatting codes.

Author: timo

lib/classtut.pod

@@ -7,6 +7,7 @@ It showcases custom constructors, private and public attributes, methods
 and various aspects of signatures. It's not very much code, and yet the
 result is interesting and, at times, useful.
 
+    =begin code
     class Task {
         has      &!callback;
         has Task @!dependencies;
@@ -41,27 +42,28 @@ result is interesting and, at times, useful.
         );
 
     $eat.perform();
+    =end code
 
 =head1 Starting with class
 
-X<class>
-X<classes>
+X<|class>
+X<|classes>
 
-X<state>
-X<has>
-X<classes, has>
-X<behavior>
-X<classes, behavior>
+X<|state>
+X<|has>
+X<|classes, has>
+X<|behavior>
+X<|classes, behavior>
 
 Perl 6, like many other languages, uses the C<class> keyword to introduce a new
 class.  The block that follows may contain arbitrary code, just as with
 any other block, but classes commonly contain state and behavior declarations.
 The example code includes attributes (state), introduced through the C<has>
 keyword, and behaviors introduced through the C<method> keyword.
 
-X<type object>
-X<defined>
-X<.defined>
+X<|type object>
+X<|defined>
+X<|.defined>
 
 Declaring a class creates a I<type object> which, by default, is
 installed into the current package (just like a variable declared with
@@ -85,11 +87,11 @@ given object is a type object or not:
 
 =head1 I can haz state?
 
-X<attributes>
-X<classes, attributes>
+X<|attributes>
+X<|classes, attributes>
 
-X<encapsulation>
-X<classes, encapsulation>
+X<|encapsulation>
+X<|classes, encapsulation>
 
 The first three lines inside the class block all declare attributes (called
 I<fields> or I<instance storage> in other languages).  These are storage
@@ -103,9 +105,9 @@ code to invoke in order to perform the task that an object represents:
 
     has &!callback;
 
-X<sigils, &>
-X<twigils>
-X<twigils, !>
+X<|sigils, &>
+X<|twigils>
+X<|twigils, !>
 
 The C<&> sigil indicates that this attribute represents something invocable.
 The C<!> character is a I<twigil>, or secondary sigil.  A twigil forms part of
@@ -126,10 +128,10 @@ The third attribute represents the state of completion of a task:
 
     has Bool $.done;
 
-X<twigils, .>
-X<twigils, accessors>
-X<accessor methods>
-X<classes, accessors>
+X<|twigils, .>
+X<|twigils, accessors>
+X<|accessor methods>
+X<|classes, accessors>
 
 This scalar attribute (with the C<$> sigil) has a type of C<Bool>.  Instead of
 the C<!> twigil, this twigil is C<.>. While Perl 6 does enforce encapsulation
@@ -153,15 +155,15 @@ change the attribute declaration:
 
     has Bool $.done is rw;
 
-X<traits, is rw>
+X<|traits, is rw>
 
 The C<is rw> trait causes the generated accessor method to return something
 external code can modify to change the value of the attribute.
 
 =head1 Methods
 
-X<methods>
-X<classes, methods>
+X<|methods>
+X<|classes, methods>
 
 While attributes give objects state, methods give objects behaviors.  Ignore
 the C<new> method temporarily; it's a special type of method.  Consider the
@@ -172,7 +174,7 @@ dependency list.
         push @!dependencies, $dependency;
     }
 
-X<invocant>
+X<|invocant>
 
 In many ways, this looks a lot like a C<sub> declaration. However, there are
 two important differences. First, declaring this routine as a method adds it to
@@ -198,7 +200,7 @@ It takes no parameters, working instead with the object's attributes. First, it
 checks if the task has already completed by checking the C<$!done> attribute.
 If so, there's nothing to do.
 
-X<operators, .>
+X<|operators, .>
 
 Otherwise, the method performs all of the task's dependencies, using the C<for>
 construct to iterate over all of the items in the C<@!dependencies> attribute.
@@ -217,7 +219,7 @@ task.
 
 =head1 Constructors
 
-X<constructors>
+X<|constructors>
 
 Perl 6 is rather more liberal than many languages in the area of constructors.
 A constructor is anything that returns an instance of the class.  Furthermore,
@@ -229,8 +231,8 @@ this example does:
         return self.bless(*, :&callback, :@dependencies);
     }
 
-X<objects, bless>
-X<bless>
+X<|objects, bless>
+X<|bless>
 
 The biggest difference between constructors in Perl 6 and constructors in
 languages such as C# and Java is that rather than setting up state on a somehow
@@ -303,6 +305,7 @@ attribute accessors.
 TODO: the example here is rather bad, and needs to be replaced (or much
 improved). See L<https://github.com/perl6/book/issues/58> for discussion.
 
+    =begin code
     class Employee {
         has $.salary;
 
@@ -321,10 +324,12 @@ improved). See L<https://github.com/perl6/book/issues/58> for discussion.
             ~ $.known_languages[0] ~ '.';
         }
     }
+    =end code
 
 Now any object of type Programmer can make use of the methods and accessors 
 defined in the Employee class as though they were from the Programmer class.
 
+    =begin code
     my $programmer = Programmer.new(
         salary => 100_000, 
         known_languages => <Perl5 Perl6 Erlang C++>,
@@ -333,13 +338,15 @@ defined in the Employee class as though they were from the Programmer class.
 
     $programmer.code_to_solve('halting problem');
     $programmer.pay();
+    =end code
 
 =head2 Overriding Inherited Methods
 
 Of course, classes can override methods and attributes defined by parent 
 classes by defining their own.  The example below demonstrates the C<Baker> class 
 overriding the C<Cook>'s C<cook> method.
 
+    =begin code
     class Cook is Employee {
         has @.utensils  is rw;
         has @.cookbooks is rw;
@@ -372,6 +379,7 @@ overriding the C<Cook>'s C<cook> method.
         salary => 50000);
 
     $baker.cook('brioche'); # Baking a tasty brioche
+    =end code
 
 Because the dispatcher will see the C<cook> method on C<Baker> before it moves up to 
 the parent class the C<Baker>'s C<cook> method will be called.
@@ -384,6 +392,7 @@ looking up a method to search for.  As a side note, Perl 6  uses the C3
 algorithm to linearize the multiple inheritance hierarchies, which is a 
 significant improvement over Perl 5's approach to handling multiple inheritance.
 
+    =begin code
     class GeekCook is Programmer is Cook {
         method new( *%params ) {
             %params<cookbooks> //= [];  # remove once Rakudo fully supports autovivification
@@ -401,6 +410,7 @@ significant improvement over Perl 5's approach to handling multiple inheritance.
 
     $geek.cook('pizza');
     $geek.code_to_solve('P =? NP');
+    =end code
 
 Now all the methods made available by both the Programmer class and the Cook
 class are available from the GeekCook class.
@@ -429,16 +439,13 @@ we can ask it a few questions:
 
 The output can look like this:
 
-=begin screen
-
+=for output
     It's an employee
     Programmer()
     Programmer.new(known_languages => ["Perl", "Python", "Pascal"],
             favorite_editor => "gvim", salary => "too small")
     code_to_solve, known_languages, favorite_editor
 
-=end screen
-
 The first two tests each smart-match against a class name. If the object is
 of that class, or of an inheriting class, it returns true. So the object in
 question is of class C<Employee> or one that inherits from it, but not
@@ -464,6 +471,7 @@ is actually a method call on the I<meta class>, which is  a class managing the
 properties of the C<Employee> class - or any other class you are interested
 in. This meta class enables other ways of introspection too:
 
+=for code
     say $o.^attributes.join(', ');
     say $o.^parents.join(', ');  
 

lib/objects.pod

@@ -151,6 +151,7 @@ accessor method.
 
 Methods are declared with the C<method> keyword inside of a class body.
 
+    =begin code
     class Journey {
         has $.origin;
         has $.destination;
@@ -170,6 +171,7 @@ Methods are declared with the C<method> keyword inside of a class body.
             "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
@@ -273,6 +275,7 @@ 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;
@@ -285,6 +288,7 @@ time. They can also be used for creating aliases for attribute initialization:
     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 parameter.
@@ -317,6 +321,7 @@ 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
 instances, and roles are meant for managing behavior and code reuse.
 
+    =begin code
     role Serializable {
         method serialize() {
             self.perl; # very primitive serialization
@@ -334,6 +339,7 @@ instances, and roles are meant for managing behavior and code reuse.
     my $serialized = $p.serialize;      # method provided by the role
     my $clone-of-p = Point.deserialization-code()($serialized);
     say $clone-of-p.x;      # 1
+    =end code
 
 Roles are immutable as soon as the compiler parses the closing bracket of the
 role declaration.
@@ -381,6 +387,7 @@ When a role contains a stubbed 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
     role AbstractSerializable {
         method serialize() { ... }  # literal ... here marks the
                                     # method as a stub
@@ -400,6 +407,7 @@ This allows you to create roles that act as abstract interfaces.
         has $.y;
         method serialize() { "p($.x, $.y)" }
     }
+    =end code
 
 The implementation of the stubbed method may also be provided by another role.
 

lib/variables.pod

@@ -240,13 +240,13 @@ file can be accessed via a Pod object, such as C<$=data>, C<$=SYNOPSIS> or
 C<=UserBlock>. That is: a variable with the same name of the desired block and a
 C<=> twigil.
 
-=begin code
+    =begin code
     =begin Foo
     ...
     =end Foo
 
     #after that, $=Foo gives you all Foo-Pod-blocks
-=end code
+    =end code
 
 You may access the Pod tree which contains all Pod structures as a hierarchical
 data structure through C<$=pod>.