<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><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><br></div><div>Happy to discuss alternatives to consider all possible use cases!</div><div><br></div><div>Thanks,</div><div>Nahuel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié., 27 de may. de 2020 a la(s) 05:13, Phil B via Cuis-dev (<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>) escribió:<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">I recall running into an issue re: Encoder changes Hernan did a while back and now I'm having a nearly identical issue related to the recent changes.<div><br></div><div>Specifically: multi-ranges and the brittleness of that code in that if you don't provide the exact right hacked version of the 'range' (i.e. sometimes it's an Interval, sometimes it's a collection of Interval), things will fail.  So now I'm having a problem after the latest changes with #noteSourceRange:forNode: complaining because I'm passing it a collection of ranges where it now expects a single range.  I'm only passing it a collection of ranges because the *previous* changes to Encoder would break if you only passed in a single range.  Of course, if I change my code back to passing a single range (i.e. undoing my fix for the last Encoder change), it breaks things elsewhere where it's expecting a collection of ranges.  Essentially the solution that I used previously was to create a MessageNode with a sourceRange: parameter that was a collection... that no longer appears to be viable.<div><br></div><div>Can this be either cleaned up (i.e. auto-detect or just use multi-ranges everywhere) or better document (and stick with!) the approach?</div><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" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div>