fix a couple of typos, grammar, and removal of whitespace
This commit is contained in:
parent
10ba9c4dc1
commit
cd73b3b12b
3 changed files with 103 additions and 103 deletions
42
doc/tut2.txt
42
doc/tut2.txt
|
|
@ -35,7 +35,7 @@ Object Oriented Programming
|
|||
===========================
|
||||
|
||||
While Nim's support for object oriented programming (OOP) is minimalistic,
|
||||
powerful OOP technics can be used. OOP is seen as *one* way to design a
|
||||
powerful OOP techniques can be used. OOP is seen as *one* way to design a
|
||||
program, not *the only* way. Often a procedural approach leads to simpler
|
||||
and more efficient code. In particular, prefering composition over inheritance
|
||||
is often the better design.
|
||||
|
|
@ -77,8 +77,8 @@ section.
|
|||
|
||||
Inheritance is done with the ``object of`` syntax. Multiple inheritance is
|
||||
currently not supported. If an object type has no suitable ancestor, ``RootObj``
|
||||
can be used as its ancestor, but this is only a convention. Objects that have
|
||||
no ancestor are implicitly ``final``. You can use the ``inheritable`` pragma
|
||||
can be used as its ancestor, but this is only a convention. Objects that have
|
||||
no ancestor are implicitly ``final``. You can use the ``inheritable`` pragma
|
||||
to introduce new object roots apart from ``system.RootObj``. (This is used
|
||||
in the GTK wrapper for instance.)
|
||||
|
||||
|
|
@ -199,7 +199,7 @@ This method call syntax is not restricted to objects, it can be used
|
|||
for any type:
|
||||
|
||||
.. code-block:: nim
|
||||
|
||||
|
||||
echo("abc".len) # is the same as echo(len("abc"))
|
||||
echo("abc".toUpper())
|
||||
echo({'a', 'b', 'c'}.card)
|
||||
|
|
@ -212,7 +212,7 @@ So "pure object oriented" code is easy to write:
|
|||
|
||||
.. code-block:: nim
|
||||
import strutils
|
||||
|
||||
|
||||
stdout.writeln("Give a list of numbers (separated by spaces): ")
|
||||
stdout.write(stdin.readLine.split.map(parseInt).max.`$`)
|
||||
stdout.writeln(" is the maximum!")
|
||||
|
|
@ -226,7 +226,7 @@ the same. But setting a value is different; for this a special setter syntax
|
|||
is needed:
|
||||
|
||||
.. code-block:: nim
|
||||
|
||||
|
||||
type
|
||||
TSocket* = object of RootObj
|
||||
FHost: int # cannot be accessed from the outside of the module
|
||||
|
|
@ -236,7 +236,7 @@ is needed:
|
|||
proc `host=`*(s: var TSocket, value: int) {.inline.} =
|
||||
## setter of hostAddr
|
||||
s.FHost = value
|
||||
|
||||
|
||||
proc host*(s: TSocket): int {.inline.} =
|
||||
## getter of hostAddr
|
||||
s.FHost
|
||||
|
|
@ -294,15 +294,15 @@ Procedures always use static dispatch. For dynamic dispatch replace the
|
|||
method eval(e: PExpr): int =
|
||||
# override this base method
|
||||
quit "to override!"
|
||||
|
||||
|
||||
method eval(e: PLiteral): int = e.x
|
||||
method eval(e: PPlusExpr): int = eval(e.a) + eval(e.b)
|
||||
|
||||
|
||||
proc newLit(x: int): PLiteral = PLiteral(x: x)
|
||||
proc newPlus(a, b: PExpr): PPlusExpr = PPlusExpr(a: a, b: b)
|
||||
|
||||
|
||||
echo eval(newPlus(newPlus(newLit(1), newLit(2)), newLit(4)))
|
||||
|
||||
|
||||
Note that in the example the constructors ``newLit`` and ``newPlus`` are procs
|
||||
because they should use static binding, but ``eval`` is a method because it
|
||||
requires dynamic binding.
|
||||
|
|
@ -316,16 +316,16 @@ dispatching:
|
|||
TThing = object of RootObj
|
||||
TUnit = object of TThing
|
||||
x: int
|
||||
|
||||
|
||||
method collide(a, b: TThing) {.inline.} =
|
||||
quit "to override!"
|
||||
|
||||
|
||||
method collide(a: TThing, b: TUnit) {.inline.} =
|
||||
echo "1"
|
||||
|
||||
|
||||
method collide(a: TUnit, b: TThing) {.inline.} =
|
||||
echo "2"
|
||||
|
||||
|
||||
var
|
||||
a, b: TUnit
|
||||
collide(a, b) # output: 2
|
||||
|
|
@ -526,7 +526,7 @@ containers:
|
|||
yield n.data
|
||||
add(stack, n.ri) # push right subtree onto the stack
|
||||
n = n.le # and follow the left pointer
|
||||
|
||||
|
||||
var
|
||||
root: PBinaryTree[string] # instantiate a PBinaryTree with ``string``
|
||||
add(root, newNode("hello")) # instantiates ``newNode`` and ``add``
|
||||
|
|
@ -578,7 +578,7 @@ simple proc for logging:
|
|||
|
||||
proc log(msg: string) {.inline.} =
|
||||
if debug: stdout.writeln(msg)
|
||||
|
||||
|
||||
var
|
||||
x = 4
|
||||
log("x has the value: " & $x)
|
||||
|
|
@ -595,7 +595,7 @@ Turning the ``log`` proc into a template solves this problem:
|
|||
|
||||
template log(msg: string) =
|
||||
if debug: stdout.writeln(msg)
|
||||
|
||||
|
||||
var
|
||||
x = 4
|
||||
log("x has the value: " & $x)
|
||||
|
|
@ -622,11 +622,11 @@ via a special ``:`` syntax:
|
|||
close(f)
|
||||
else:
|
||||
quit("cannot open: " & fn)
|
||||
|
||||
|
||||
withFile(txt, "ttempl3.txt", fmWrite):
|
||||
txt.writeln("line 1")
|
||||
txt.writeln("line 2")
|
||||
|
||||
|
||||
In the example the two ``writeln`` statements are bound to the ``body``
|
||||
parameter. The ``withFile`` template contains boilerplate code and helps to
|
||||
avoid a common bug: to forget to close the file. Note how the
|
||||
|
|
@ -739,7 +739,7 @@ Term rewriting macros
|
|||
---------------------
|
||||
|
||||
Term rewriting macros can be used to enhance the compilation process
|
||||
with user defined optimizations; see this `document <trmacros.html>`_ for
|
||||
with user defined optimizations; see this `document <trmacros.html>`_ for
|
||||
further information.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue