better CSS; better docs for teh tables module

This commit is contained in:
Araq 2014-12-21 15:59:01 +01:00
commit 2990a9224b
3 changed files with 20 additions and 13 deletions

View file

@ -227,7 +227,6 @@ body {
padding-top: 10%; } padding-top: 10%; }
p.module-desc { p.module-desc {
font-style: italic;
font-size: 1.1em; font-size: 1.1em;
color: #666666; } color: #666666; }
@ -559,7 +558,8 @@ pre {
.pre { .pre {
font-family: "Source Code Pro", Monaco, Menlo, Consolas, "Courier New", monospace; font-family: "Source Code Pro", Monaco, Menlo, Consolas, "Courier New", monospace;
font-weight: 600; font-weight: 600;
color: #504da6; } /*color: #504da6;*/
}
code { code {
padding: 2px 4px; padding: 2px 4px;

View file

@ -1,14 +1,20 @@
# #
# #
# Nim's Runtime Library # Nim's Runtime Library
# (c) Copyright 2013 Andreas Rumpf # (c) Copyright 2014 Andreas Rumpf
# #
# See the file "copying.txt", included in this # See the file "copying.txt", included in this
# distribution, for details about the copyright. # distribution, for details about the copyright.
# #
## The ``tables`` module implements an efficient hash table that is ## The ``tables`` module implements variants of an efficient hash table that is
## a mapping from keys to values. ## a mapping from keys to values. ``Table`` is the usual hash table,
## ``OrderedTable`` is like ``Table`` but remembers insertion order
## and ``CountTable`` is a mapping from a key to its number of occurances.
## For consistency with every other data type in Nim these have **value**
## semantics, this means that ``=`` performs a copy of the hash table.
## For **reference** semantics use the ``Ref`` variant: ``TableRef``,
## ``OrderedTableRef``, ``CountTableRef``.
## ##
## If you are using simple standard types like ``int`` or ``string`` for the ## If you are using simple standard types like ``int`` or ``string`` for the
## keys of the table you won't have any problems, but as soon as you try to use ## keys of the table you won't have any problems, but as soon as you try to use
@ -24,9 +30,15 @@
## ##
## What is happening here is that the types used for table keys require to have ## What is happening here is that the types used for table keys require to have
## a ``hash()`` proc which will convert them to a `THash <hashes.html#THash>`_ ## a ``hash()`` proc which will convert them to a `THash <hashes.html#THash>`_
## value, and the compiler is listing all the hash functions it knows. After ## value, and the compiler is listing all the hash functions it knows.
## you add such a proc for your custom type everything will work. See this ## Additionally there has to be a ``==`` operator that provides the same
## example: ## semantics as its corresponding ``hash`` proc.
##
## After you add ``hash`` and ``==`` for your custom type everything will work.
## Currently however ``hash`` for objects is not defined, whereas
## ``system.==`` for objects does exist and performs a "deep" comparison (every
## field is compared) which is usually what you want. So in the following
## example implementing only ``hash`` suffices:
## ##
## .. code-block:: ## .. code-block::
## type ## type
@ -51,9 +63,6 @@
## p2.firstName = "소진" ## p2.firstName = "소진"
## p2.lastName = "박" ## p2.lastName = "박"
## salaries[p2] = 45_000 ## salaries[p2] = 45_000
##
## **Note:** The data types declared here have *value semantics*: This means
## that ``=`` performs a copy of the hash table.
import import
hashes, math hashes, math

View file

@ -1,8 +1,6 @@
version 0.10 version 0.10
============ ============
- document the tables module better
- The bitwise 'not' operator will be renamed to 'bnot' to - The bitwise 'not' operator will be renamed to 'bnot' to
prevent 'not 4 == 5' from compiling. -> requires 'mixin' annotation for procs! prevent 'not 4 == 5' from compiling. -> requires 'mixin' annotation for procs!
- A named tuple will be compatible to a tuple with different names. - A named tuple will be compatible to a tuple with different names.