54 lines
1.6 KiB
Plaintext
54 lines
1.6 KiB
Plaintext
% BE SURE TO EDIT design.ptex
|
|
\documentclass{article}
|
|
|
|
\usepackage{rcs}
|
|
\RCS $Date: 2000/03/04 15:45:59 $
|
|
\RCS $Revision: 1.1 $
|
|
\date{Rev.\RCSRevision~~\RCSDate}
|
|
|
|
\title{Dimension-based thinking for ZigZag}
|
|
\author{Tuomas J. Lukka}
|
|
\begin{document}
|
|
\maketitle
|
|
|
|
\def\zz{ZigZag}
|
|
|
|
\section{Introduction}
|
|
|
|
When designing the code to implement a \zz\ space, the
|
|
place most people would start at would be the cell object, which would
|
|
have a set of pointers to other cells, named with dimension names.
|
|
However, this is not the only way to structure the internals - indeed,
|
|
it is not necessarily a good way at all.
|
|
|
|
\section{Dimension-based view}
|
|
|
|
With cells, you have to always take steps to enforce the two-directional
|
|
connection consistency rule.
|
|
The dimension-based view starts from the realization that if we consider
|
|
each {\em dimension} an entity by itself, this gets much simpler:
|
|
simply put, each dimension is a one-to-one mapping from some cells of the
|
|
space to some other cells.
|
|
|
|
\section{Advantages}
|
|
|
|
The dimension-based view has several advantages:
|
|
\begin{itemize}
|
|
\item {\bf Specialization}
|
|
It is much easier to define a single dimension object to
|
|
do something different than the others, e.g. a dimension where
|
|
getting the {\it n}th cell is fast but inserting and deleting cells
|
|
is allowed to be slow.
|
|
\item {\bf Simplicity}
|
|
Since one object is in charge of the both ends of a connection,
|
|
it is easier to avoid mistakes. Coding transient cell connections
|
|
is easy as well, as that object can keep tabs on the transient
|
|
connections separate from the stable ones.
|
|
|
|
|
|
|
|
% .PS
|
|
% box "Clang" ht 0.25
|
|
% .PE
|
|
% $$\box\graph$$
|