<div dir="ltr">On Wed, Jan 30, 2013 at 10:50 AM, Frank Shearar <span dir="ltr">&lt;<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 30 January 2013 18:33,  &lt;<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>&gt; wrote:<br>

&gt; Frank Shearar uploaded a new version of Kernel to project The Inbox:<br>
&gt; <a href="http://source.squeak.org/inbox/Kernel-fbs.735.mcz" target="_blank">http://source.squeak.org/inbox/Kernel-fbs.735.mcz</a><br>
&gt;<br>
&gt; ==================== Summary ====================<br>
&gt;<br>
&gt; Name: Kernel-fbs.735<br>
&gt; Author: fbs<br>
&gt; Time: 30 January 2013, 6:33:47.078 pm<br>
&gt; UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc<br>
&gt; Ancestors: Kernel-fbs.734<br>
&gt;<br>
&gt; Actually, return a Message, and find out the receiver of the Message from the signalercontext.<br>
&gt;<br>
&gt; Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method.<br>
&gt;<br>
&gt; =============== Diff against Kernel-fbs.734 ===============<br>
&gt;<br>
&gt; Item was added:<br>
&gt; + ----- Method: ContextPart&gt;&gt;asMessage (in category &#39;converting&#39;) -----<br>
&gt; + asMessage<br>
&gt; +       | sender selector args |<br>
&gt; +       sender := self sender.<br>
&gt; +       selector := sender method selector.<br>
&gt; +       args := Array new: selector numArgs.<br>
&gt; +       1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].<br>
&gt; +       ^ Message selector: selector arguments: args.!<br>
&gt;<br>
&gt; Item was removed:<br>
&gt; - ----- Method: ContextPart&gt;&gt;asMessageSend (in category &#39;converting&#39;) -----<br>
&gt; - asMessageSend<br>
&gt; -       | sender selector args |<br>
&gt; -       sender := self sender.<br>
&gt; -       selector := sender method selector.<br>
&gt; -       args := Array new: selector numArgs.<br>
&gt; -       1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].<br>
&gt; -       ^ MessageSend receiver: self receiver selector: selector arguments: args.!<br>
<br>
</div></div>&lt;snip&gt;<br>
<br>
Diffs serve as a helper for reviewers. To that end, the diffs ought to<br>
actually show what changes would be applied to trunk should the change<br>
be accepted. This diff, for instance, shows the removal of<br>
#asMessageSend and the addition of #asMessage, but really the change<br>
applied to trunk will be just the addition of #asMessage.<br>
<br>
In other words when something undergoes a few rounds of review (and<br>
I&#39;d think this should be the _norm_) the reviewer must reconstruct a<br>
series of diffs to get an idea of how trunk will change.<br>
<br>
Wouldn&#39;t it be better to diff against trunk rather than against the<br>
mcz&#39;s ancestor? (*)<br>
<br>
frank<br></blockquote><div style>Yes, it would be better to diff against trunk.  But &#39;Trunk&#39; isn&#39;t a defined state - what you have currently as Trunk isn&#39;t what I have currently as trunk - I haven&#39;t updated as recently as you have, for instance, so the changes that will be applied if I accepted/updated will be different than if you accept/update.</div>
<div style><br></div><div style>Maybe you are talking about diffs against the most recent predecessor in the Trunk Repository?  That should be doable - but if there is no predecessor (a completely new package is moved in), then all of the messages are new.</div>
<div style><br></div><div style>-Chris</div></div></div></div>