<div dir="ltr"><div dir="ltr">Hi Phil,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 1, 2020 at 5:13 PM Phil B <<a href="mailto:pbpublist@gmail.com">pbpublist@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="ltr">Hernan,<div><br></div><div>Since you are changing both the content and behavior, I'm not sure test cases would be much help. </div></div></div></div></blockquote><div><br></div><div>oh yes it would help! If we make a change and see a test failing we have to see why and understand the reason, etc.</div><div>For example, if we would have run your tests after this change and some of them would have failed, we would have contacted you about it before pushing the change and avoid any bad surprise </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="ltr"><div> It's the ongoing shifting around without understanding where things are going to land that's causing me pain. What would make things easier on me is, to the extent possible, in one set of changes get the external interfaces looking and behaving from the outside the way you want them long term... regardless of what's going on internally. I'd rather see one set of changes that break everything at once than 5 smaller sets that break it a little at a time.</div><div><br></div><div>In the short term, that might mean renaming any methods you want now. On the methods that you expect to accept/return a collection of Interval, put asserts to that effect. The same thing for any methods you expect to accept/return singular Interval. That way it's clear what is expected where and you are free to do whatever you need to behind the curtains. When you get to the final desired end state, and assuming everything is using a unified set of assumptions/interfaces, then just drop the asserts and any obsolete methods.</div></div></div></div></blockquote><div><br></div><div>I understand your point but it is difficult to know how everybody is using the system. When I added the change I thought it was harmless because it added range information on nodes that where not in the ranges dictionary. In fact, no Cuis tool broke. Because I did not know you were using the ranges information in a different way it is used by the Cuis tools is that I could not prevent this change from breaking what you have.</div><div>If I would have run tests related to what you do, and those test would have failed, the history would have been different.</div><div>If you have tests to run on the packages you are developing please let me know to add them when we make this kind of changes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="ltr"><div><br></div><div dir="auto"><span style="font-family:sans-serif">On the other hand, if the plan is to have the nodes keep track of the ranges, do the recent changes even help you get there? If not, why are you bothering to clean up something that's going to go away? (That's creating more work for both you and me... and I'm really lazy so that bums me out 😂</span></div></div></div></div></blockquote><div><br></div><div>Well you know that ideas do not pop up in the best order :-)</div><div>And as you may also know, we are making all these things on our free time, that it is scarce, so trade offs between time, impact, change deep and so on have to be made.</div><div><br></div><div>Anyway, I hope we wont break your code again. If you have tests we can run, that will help a lot.</div><div><br></div><div>Cheers!</div><div>Hernan. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="ltr"><div dir="auto"><span style="font-family:sans-serif"></span><br></div><div dir="auto"><br></div><div>Thanks,</div><div>Phil</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 1, 2020 at 2:26 PM Hernan Wilkinson <<a href="mailto:hernan.wilkinson@10pines.com" rel="noreferrer" target="_blank">hernan.wilkinson@10pines.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Phil!<div> I agree that we should convert the value of the ranges dictionary to a collection of intervals and make them polymorphic once and for all. Sadly that is a change that requires time and great care because it is used in many places (parser, debugger, etc). </div><div> I think the best change would be for AST nodes to know their range and get rid of that dictionary in the encoder, that is something that Nahuel has been analyzing lately but again, it is not an easy change.</div><div> </div><div>I would like to avoid the problems we are generating to you with these changes... are there tests we can run to be sure we have not break you anything?</div><div><br></div><div>Cheers!</div><div>Hernan.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 28, 2020 at 3:48 AM Phil B via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" rel="noreferrer" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Nahuel,<div><br></div><div>Thanks for the response... it gave me a chance to calm down and take a closer look at what you changed...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 27, 2020 at 5:51 PM Nahuel Garbezza <<a href="mailto:n.garbezza@gmail.com" rel="noreferrer" target="_blank">n.garbezza@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Phil,<div><br></div><div>As you were mentioning, the update #4156 enforces that #noteSourceRange:forNode: should always receive an interval instead of a collection. Before this update it worked with both intervals and collection of intervals, kind of a "weird polymorphism" case (because the object was only put into a dictionary, we didn't have any issues). When I looked at all the senders of that message, I saw that we are always passing a single range instead of a collection, that's why I went ahead with the change.</div></div></blockquote><div><br></div><div>My issue with these changes since they were originally made was that the interface and internal representation, while simple, are rather ugly IMO. It looks like your changes are addressing the ambiguous interface (to a degree) but not the internal representation, which senders must still be aware of. My code being outside of the changesets gets to see the ugliness first hand...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I'm not sure if I understood correctly the issue you are having. Have you tried using #addMultiRange:for: message? this one is for the nodes that should have collections of source ranges (the nodes that have multiple occurrences on the same AST, like variables). The reason for having two messages for adding source ranges is for the user to explicitly decide when to report a multi range vs. report a single range. Another option could be to have a message like #noteSourceRanges:forNode: (note the plural) to be used with a collection of source ranges, and report all source ranges at once.</div></div></blockquote><div><br></div><div>The issue is the parallel, yet incompatible, accessors of the same ivar (sourceRanges) depending on whether you want a singular range or a multi range. As a result, the sender of the setter and getter must be coordinated on a per-node basis or you will have problems... which is what was happening with my code.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Happy to discuss alternatives to consider all possible use cases!</div></div></blockquote><div><br></div><div>Why not just convert everything to use multi ranges (i.e. internally *always* store a collection in sourceRanges) and eliminate the issue of needing to be aware of the internal representation entirely?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks,</div><div>Nahuel</div></div><br></blockquote><div><br></div><div>Thanks,</div><div>Phil </div></div></div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" rel="noreferrer" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal"><span style="font-weight:bold">Hernán Wilkinson</span><br>Agile Software Development, Teaching & Coaching</span></font></span></span></span></strong></span></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">Phone: +54-011</span></font></span></span></span></strong></span><font face="tahoma, sans-serif" size="2">-4893-2057</font></div><div><strong style="font-family:tahoma,sans-serif;font-size:xx-small"><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Twitter: @HernanWilkinson</span></font></span></span></strong></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">site: <a href="http://www.10pines.com/" style="color:rgb(17,65,112)" rel="noreferrer" target="_blank">http://www.10Pines.com</a></span></font></span></span></span></strong></span></div><div><font face="tahoma, sans-serif"><span style="border-collapse:collapse">Address: Alem 896</span></font>, Floor 6, Buenos Aires, Argentina</div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal"><span style="font-weight:bold">Hernán Wilkinson</span><br>Agile Software Development, Teaching & Coaching</span></font></span></span></span></strong></span></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">Phone: +54-011</span></font></span></span></span></strong></span><font face="tahoma, sans-serif" size="2">-4893-2057</font></div><div><strong style="font-family:tahoma,sans-serif;font-size:xx-small"><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Twitter: @HernanWilkinson</span></font></span></span></strong></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">site: <a href="http://www.10pines.com/" style="color:rgb(17,65,112)" target="_blank">http://www.10Pines.com</a></span></font></span></span></span></strong></span></div><div><font face="tahoma, sans-serif"><span style="border-collapse:collapse">Address: Alem 896</span></font>, Floor 6, Buenos Aires, Argentina</div></div></div></div></div></div></div></div></div></div></div></div></div>