|
[Rivet-svn] r4301 - trunk/docblackhole at projects.hepforge.org blackhole at projects.hepforge.orgThu 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 |