[Rivet-svn] r4301 - trunk/doc

blackhole at projects.hepforge.org blackhole at projects.hepforge.org
Thu May 23 11:25:28 BST 2013


Author: buckley
Date: Thu May 23 11:25:28 2013
New Revision: 4301

Log:
Just a textual tweak

Modified:
   trunk/doc/writinganalyses.tex

Modified: trunk/doc/writinganalyses.tex
==============================================================================
--- trunk/doc/writinganalyses.tex	Tue May 21 15:55:04 2013	(r4300)
+++ trunk/doc/writinganalyses.tex	Thu May 23 11:25:28 2013	(r4301)
@@ -258,13 +258,13 @@
   registered, nor whether the downcast to the requested concrete type is
   legal. These are very legitimate concerns!
 
-  In truth, we'd like to have this level of extra safety! But in the past, when
-  projections were held as members of \code{ProjectionApplier} classes rather
-  than in the central \code{ProjectionHandler} repository, the benefits of the
-  strong typing were outweighed by more serious and subtle bugs relating to
-  projection lifetime and object ``slicing''. At least when the current approach
-  goes wrong it will throw an unmissable \emph{runtime} error --- until it's
-  fixed, of course! --- rather than silently do the wrong thing.
+  In truth, we'd like to have this level of extra safety: who wouldn't? But in
+  the past, when projections were held as members of \code{ProjectionApplier}
+  classes rather than in the central \code{ProjectionHandler} repository, the
+  benefits of the strong typing were outweighed by more serious and subtle bugs
+  relating to projection lifetime and object ``slicing''. At least when the
+  current approach goes wrong it will throw an unmissable \emph{runtime} error
+  --- until it's fixed, of course! --- rather than silently do the wrong thing.
 
   Our problems here are a microcosm of the perpetual language battle between
   strict and dynamic typing, runtime versus compile time errors. In practice,


More information about the Rivet-svn mailing list