[Cuis-dev] Recent changes to Encoder (update 4156?)

[Nahuel Garbezza]

Hi Phil,

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.

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.

Happy to discuss alternatives to consider all possible use cases!

Thanks,
Nahuel

El mié., 27 de may. de 2020 a la(s) 05:13, Phil B via Cuis-dev (
cuis-dev at lists.cuis.st) escribió:

> 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.
>
> 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.
>
> Can this be either cleaned up (i.e. auto-detect or just use multi-ranges
> everywhere) or better document (and stick with!) the approach?
>
> Thanks,
> Phil
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200527/a3c04bce/attachment.htm>