From 4281e79b4d396ba9133f6603389b07cbd8b4ffd8 Mon Sep 17 00:00:00 2001
From: Jean Privat <jean@pryen.org>
Date: Fri, 27 Sep 2019 08:53:55 -0400
Subject: [PATCH] manual: fix examples to be nitunitables

Signed-off-by: Jean Privat <jean@pryen.org>
---
 doc/manual/attribute.md   |   30 +++++++++++++--------------
 doc/manual/constructor.md |   50 +++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 63 insertions(+), 17 deletions(-)

diff --git a/doc/manual/attribute.md b/doc/manual/attribute.md
index e9741e9..cd7da73 100644
--- a/doc/manual/attribute.md
+++ b/doc/manual/attribute.md
@@ -16,7 +16,7 @@ end
 
 Note that from an API point of view, there is no way to distinguish the read access of an attribute with a normal method neither to distinguish a write access of an attribute with a setter. Therefore, the read access of an attribute is called a getter while the write access is called a setter.
 
-~~~
+~~~nitish
 var x = foo.bar # Is bar an attribute or a method?
 foo.bar = y # Is bar an attribute or a setter?
 # In fact, we do not need to know.
@@ -28,12 +28,12 @@ By default, a getter is public and a setter is private. The visibility of getter
 additional `writable` keyword.
 
 ~~~
-class Foo
-    var pub_pri: X
-    protected var pro_pri: X
-    var pub_pub: X is writable
-    private var pri_pro: X is protected writable
-    var pub_pri2: X is private writable # the default
+class Foo2
+    var pub_pri: Int
+    protected var pro_pri: Int
+    var pub_pub: Int is writable
+    private var pri_pro: Int is protected writable
+    var pub_pri2: Int is private writable # the default
 end
 ~~~
 
@@ -43,17 +43,17 @@ Getters and setters of attributes behave like genuine methods that can be inheri
 a redefinition while `redef writable` declares that the setter is a redefinition.
 
 ~~~
-interface Foo
+interface Foo3
     fun derp: Int is abstract
     fun derp=(o: Int) is abstract
 end
-class Bar
-    super Foo
-    redef var derp: Int redef writable
+class Bar3
+    super Foo3
+    redef var derp is redef writable
 end
-class Baz
-    super Bar
-    redef fun derp do ...
-    redef fun derp=(o) do ...
+class Baz3
+    super Bar3
+    redef fun derp do return 1
+    redef fun derp=(o) do end
 end
 ~~~
diff --git a/doc/manual/constructor.md b/doc/manual/constructor.md
index 39bfe53..51439a4 100644
--- a/doc/manual/constructor.md
+++ b/doc/manual/constructor.md
@@ -27,6 +27,11 @@ assert p.id == "ABC"
 In subclasses, additional attributes are automatically collected.
 
 ~~~
+class Product
+	var id: String
+	var description: String
+	var price: Float
+end
 class Book
 	super Product
 	var author: String
@@ -44,6 +49,11 @@ It is used to perform additional systematic tasks.
 Because the `init` is run at the end of the initialization sequence, initialized attributes are usable in the body.
 
 ~~~
+class Product
+	var id: String
+	var description: String
+	var price: Float
+end
 class OverpricedProduct
 	super Product
 	init
@@ -52,7 +62,7 @@ class OverpricedProduct
 	end
 end
 var op = new OverpricedProduct("ABC", "Bla bla", 15.95)
-assert op.price == 159.50
+assert op.price.is_approx(159.50, 0.001)
 ~~~
 
 
@@ -65,6 +75,11 @@ There is three cases for an attributes to not be collected in the `new`.
 * Attributes introduced in refinement of classes
 
 ~~~
+class Product
+	var id: String
+	var description: String
+	var price: Float
+end
 class TaxedProduct
 	super Product
 	var tax_rate = 9.90
@@ -75,7 +90,7 @@ class TaxedProduct
 	end
 end
 var tp = new TaxedProduct("ABC", "Bla bla", 15.95)
-assert tp.total_price == 17.52905
+assert tp.total_price.is_approx(17.52905, 0.00001)
 ~~~
 
 Note: The orchestration here is important. In order, the following is executed:
@@ -95,6 +110,11 @@ In fact, by default, the setter of an attribute is used as a initializer.
 `autoinit` is used to register a method as a setter.
 
 ~~~
+class Product
+	var id: String
+	var description: String
+	var price: Float
+end
 class FooProduct
 	super Product
 	fun set_xy(x, y: Int) is autoinit do z = x * 10 + y
@@ -113,6 +133,32 @@ In most case, there is no reason that an argument of a `new` construction is not
 As explained above, one of the main advantage of these constructors is their compatibility with multiple inheritance.
 
 ~~~
+class Product
+	var id: String
+	var description: String
+	var price: Float
+end
+class OverpricedProduct
+	super Product
+	init
+	do
+		price = price * 10.0
+	end
+end
+class TaxedProduct
+	super Product
+	var tax_rate = 9.90
+	var total_price: Float is noinit
+	init
+	do
+		total_price = price * (1.0 + tax_rate/100.0)
+	end
+end
+class FooProduct
+	super Product
+	fun set_xy(x, y: Int) is autoinit do z = x * 10 + y
+	var z: Int is noinit
+end
 class MultiProduct
 	super OverpricedProduct
 	super TaxedProduct
-- 
1.7.9.5