[Rivet] Dangerous casting to FinalState

[Andy Buckley]

For what it's worth, I'm happy to put the patch into this release. It'll
block compilation of code with FinalState projection slicing, albeit
with an unclear error message, and I think we do want that.

For the following major release, it'd be good to solve this more
completely. FinalStates are the only significant subset of projections
which can have this problem, because FinalState itself is not virtual.
If we were to make it virtual (maybe renaming to FinalStateBase), and
push the charged+neutral final particle finding job into another derived
class, then there would be no problem. We anyway need to rationalise the
relationship between ParticleFinders and FinalStates (and I think we
should also remove the LossyFinalState and all the surrounding,
virtually unused, mechanisms.)

'Nuff said; full speed ahead ;-)

Andy


On 14/07/15 14:17, Chris Pollard wrote:
> Hi Frank,
> 
> I don't see any objections, so could you include your patch and push to
> the main repo? I will then run the validation tonight.
> 
> Chris
> 
> On Mon, Jul 13, 2015 at 7:35 PM, Frank Siegert <frank.siegert at cern.ch
> <mailto:frank.siegert at cern.ch>> wrote:
> 
>     Hi Chris,
> 
>     >> So we might as well go ahead with my patch, since it will save users
>     >> from this silly slicing mistake. And we will have to fix the
>     >> projection registration mechanism anyway if we want to allow copying
>     >> of projections by value. Though I didn't quite understand David's last
>     >> comment: do you find the patch ok, or not (assuming we only care about
>     >> FinalState-derived projections at the moment)? Any other objections?
>     >
>     > I don't object to the solution per se, but my preference is to fix the
>     > copy-by-value issue correctly throughout the Projection inheritance
>     > hierarchy instead of patching just FinalState. If this is the solution we
>     > choose, great, but let's fix the whole tree. Do you agree?
> 
>     Sounds good to me. Do you plan to have this already for this release?
>     If not, I still see no reason to not use my patch as an intermediate
>     stop-gap measure, which will be amended by a solution for all
>     Projections at some point.
> 
>     Cheers,
>     Frank
> 
> 
> 
> 
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
> 


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow