<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2 Jun 2015, at 16:59, Frank Löffler &lt;<a href="mailto:knarf@cct.lsu.edu">knarf@cct.lsu.edu</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Tue, Jun 02, 2015 at 04:44:46PM +0200, Ian Hinder wrote:<br><blockquote type="cite">Indeed. &nbsp;If you (still) have access to Mathematica.<br></blockquote><br>How many thorns are we talking about? If you don't intent to regenerate<br>them, maybe this could be done once, by a script?<br></blockquote><div><br></div><div>That's not what I'm getting at; we can of course fix all the ET Kranc-generated thorns to keep up with the ever-changing flesh. &nbsp;It's a matter of policy regarding backward compatibility.</div><br><blockquote type="cite"><blockquote type="cite">I just don't see the point of deliberately breaking backward<br>compatibility, even in the case where the old behaviour was not in<br>agreement with the documentation. &nbsp;What is the benefit of doing this?<br></blockquote><br>It prevents new code from using this. Old thorns cannot be expected to<br>work forever with a changing framework. </blockquote><div><br></div><div>I disagree completely. &nbsp;Cactus should be a stable platform on which you can build application thorns. &nbsp;New versions of this platform should still be able to run old code. &nbsp;Especially in this case, where there is no benefit to the change apart from discouraging new thorns using the old way. &nbsp;I think a warning should be enough.</div><div><br></div><blockquote type="cite">Leaving old stuff in for ever<br>usually makes code unmaintainable, although I don't know how severe it<br>would be in this case. We didn't intent to make this go away<br>immediately, more like marking it deprecated and generating a warning<br>now, and removing it from a release in a year at the earliest.<br></blockquote><div><br></div><div>Usually this sort of change is very annoying. In isolation, you can just say "it's a simple change, why are you complaining?" &nbsp;But when trying to resurrect an old thorn, it's unlikely that this is the only problem you're going to have, and each one makes life harder. &nbsp;I agree that leaving in a huge amount of backward-compatibility code can make the code harder to maintain, which is why in the ticket I said that it could be removed if that were the case. &nbsp;But I don't think that is the case here, and I don't see a benefit to removing the code.</div><div><br></div></div><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>--&nbsp;</div><div>Ian Hinder</div><div><a href="http://members.aei.mpg.de/ianhin">http://members.aei.mpg.de/ianhin</a></div></div></div></div></div>
</div>
<br></body></html>