% -*- TeX-master: "finaler.tex" -*-

\label{sec:properties}

The properties system exists to abstract out and unify the process of
getting and setting ``properties'' of objects.  It is designed to be
a general support library, and as such has no dependency on any of the
other \Gizmoball components.  However, as such, it is used throughout
\Gizmoball as a general mechanism to decrease coupling between the
components.

The properties system leverages an approach similar to that of
JavaBeans.\footnote{With the advent of Sun's JavaBean technology, one
  can finally answer the immortal question "What does that have to do
  with the price of Beans in Africa?" Because the JavaBean API is
  certified 100\% Pure Java and Java itself is portable, the price of
  Beans in Africa is the same as it is nearly anywhere else in the
  world.  However, we decided that the price of Beans was nevertheless
  too high to warrant their use in Gizmoball, instead choosing to
  implement our own property framework similar in spirit to JavaBean's
  property capabilities, but taylored to fit our needs without the
  overhead incurred by the other capabilities of JavaBeans.}  Like
JavaBeans, it assumes objects will follow a particular design pattern
with get and set methods for accessing their properties.  It presents
unified methods to access the value of and set the value of any
presented properties by name.  The property system works through
reflection, leveraging objects' existing get and set methods, thus
allowing it to be combined with virtually any object without any
change or penalty to code that does not need the unified access of the
property system, while still incurring minimum changes to objects
presenting their properties through the system.  The run-time nature
of the property system makes it more prone to certain types of errors
that would normally be caught at compile-time, but it gives it a great
deal more flexibility than pure compile-time code has.

There are three things objects are required to do in order to present
their properties through this system:

\begin{itemize}
\item Extend \texttt{gizmoball.property.Propertyified}
\item Report what properties the object supports (in the form of a
  list of property names)
\item Call a method that in turns fires property observers when a set
  method is called
\end{itemize}

The property system is the base of the ``zero-knowledge'' systems in
\Gizmoball because, despite knowing nothing about the properties of
objects at compile-time, it can present them for use by other systems.
Thus, by leveraging the properties system, other components of
\Gizmoball can also be designed as zero-knowledge systems.  All of the
gizmos are written on top of the property system.  This allows the
game serializer (see Section~\ref{sec:serializer}) to get and set the
properties of gizmos as they are loaded and saved without requiring
knowledge of the types of gizmos it is loading or saving.  The editor
uses it to deduce which frobbers to display for a gizmo, as well as to
display the properties table and keep it up to date.  Because these
systems are completely decoupled, it is trivial to add new gizmos and
change the properties that gizmos support; the remaining systems
simply adapt to these changes at run-time.

The representation of the property system is fairly straightforward
due to the fact that the values of the properties are all being stored
in the classes that use the property system and not in the system
itself.  Otherwise, it makes ample use of reflection-based types to
capture the methods and classes it uses to access properties.

We also considered using a non-reflection based property system which
would have been more efficient.  However, it would have required a
great deal of additional support from objects implementing
properties.  Furthermore, it would not have fixed the only reasonable
problem with the properties system, that is, the lack of compile-time
checking.  Because the property system is never used by \Gizmoball
under real-time circumstances, the decreased efficiency of the
reflection based solution is acceptable.