<div dir="ltr">Hi Frank,<div><br></div><div>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.</div><div><br></div><div>Chris</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 13, 2015 at 7:35 PM, Frank Siegert <span dir="ltr"><<a href="mailto:frank.siegert@cern.ch" target="_blank">frank.siegert@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chris,<br>
<span class=""><br>
>> So we might as well go ahead with my patch, since it will save users<br>
>> from this silly slicing mistake. And we will have to fix the<br>
>> projection registration mechanism anyway if we want to allow copying<br>
>> of projections by value. Though I didn't quite understand David's last<br>
>> comment: do you find the patch ok, or not (assuming we only care about<br>
>> FinalState-derived projections at the moment)? Any other objections?<br>
><br>
> I don't object to the solution per se, but my preference is to fix the<br>
> copy-by-value issue correctly throughout the Projection inheritance<br>
> hierarchy instead of patching just FinalState. If this is the solution we<br>
> choose, great, but let's fix the whole tree. Do you agree?<br>
<br>
</span>Sounds good to me. Do you plan to have this already for this release?<br>
If not, I still see no reason to not use my patch as an intermediate<br>
stop-gap measure, which will be amended by a solution for all<br>
Projections at some point.<br>
<br>
Cheers,<br>
Frank<br>
</blockquote></div><br></div>