<div dir="ltr"><div>Can you represent empty ranges?</div><div><br></div><div>For example,</div><div>(5,5) could be empty (marking a position before or after 5th character - your choice)</div><div> (5,6) a one character range (from left to right)</div><div>(5,4) too (from right to left).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 11 mai 2020 à 01:22, Phil B via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> a écrit :<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">Luciano,</div><div dir="ltr"><br></div><div>Since the vast majority of ranges I'd be working with are programmatically created, #.. wouldn't really help me (i.e. Range #from:to: would be fine and consistent with Interval in meaning) but I'm not opposed to it if it would help you. However, I would not be in favor of overloading #, since that seems confusing given other implementors of #,.</div><div><br></div><div>Thanks,</div><div>Phil</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 10, 2020 at 4:38 PM Luciano Notarfrancesco <<a href="mailto:luchiano@gmail.com" target="_blank">luchiano@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><div dir="auto">If you’re going to make Range concrete, let me suggest allowing #.. as a binary selector and creating ranges like 1..10 or 10..1. If you don’t make Range concrete it would be nice to have available the #.. anyways. The selector #, also comes to mind but I’m using it for pairs and tuples. </div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 May 2020 at 2:57 AM, Phil B via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" 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">Hernan,<div><br></div><div>OK, I'll hang back and see how yours evolves. Here's what I'm thinking would address my needs:</div><div><br></div><div>Range:</div><div>start and end are both integers</div><div>count is implicit and either 1 or -1 (if start<end, it's 1.. otherwise -1)</div><div>Provide #asInterval for infrequent use cases where you need the extra flexibility</div><div><br></div><div>SourceCodeRange:</div><div>0<start<=end</div><div>Mostly used as a container for start and end (i.e. need getters)</div><div>Next most common use is simple enumeration (esp #do:, #withIndexDo:, #reverseDo: , #select:, #collect: and #with:* variants)</div><div><br></div><div>The main requirement is that they are small and fast... I need lots of them and use them heavily. I just did a quick check in my image and it currently has ~9k SHRange instances. In OMeta I use many more 'range' (i.e. currently Association) instances than that. (up to millions would not be out of the question when parsing a large data file... a bit of an edge case, but still real-world)</div><div><br></div><div>Thanks,</div><div>Phil</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 10, 2020 at 3:17 PM Hernan Wilkinson <<a href="mailto:hernan.wilkinson@10pines.com" 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, <br><div> great observation! </div><div> I proposed to Nahuel to subclass Interval (he thought the same design that you suggested) to keep polymorphism at the beginning so he could start using SourceCodeRange immediately, and then make a refactoring to get the model you suggested. So this is just a first step, we will see how it evolves.</div><div><br></div><div>Hernan.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 10, 2020 at 3:53 PM Phil B via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" 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">Actually, Object->Range->SourceCodeRange probably makes more sense. Non-Interval ranges are useful for things beyond source code.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 10, 2020 at 2:37 PM Phil B <<a href="mailto:pbpublist@gmail.com" target="_blank">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="ltr"><div dir="ltr">Hi Nahuel,<div><br></div><div>Interesting timing as I was thinking along the same lines in the last few days. However, I think an Interval subclass is the wrong way to do it given the relative inefficiency of Interval as the parent class. How about something along the lines of a SourceCodeRange class (a subclass of Object?) which just stores the start/end (or first/last... whatever) of the range and add whatever methods from Interval we find appropriate? Then we could make things like SHRange subclasses of it. Basically the convenience and (mostly) behavior of an Interval without the overhead.</div><div><br></div><div>What got me thinking about this is the OMeta uses Association to store first/last of ranges to *avoid* using Interval. But I've always disliked using an Association this way and would like to switch to something else as long as it's efficient.</div><div><br></div><div>Thanks,</div><div>Phil</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 10, 2020 at 2:24 PM Nahuel Garbezza via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" 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">Hi! <br><div><br></div><div>I'm attaching a changeset (+ tests changeset) with the following:</div><div><br></div><div>Main changes:<br><br>Introduce the SourceCodeInterval class as a specialization of Interval, capable of dealing with source code transformations. Start to use SourceCodeInterval in the source ranges reported by the Parser, and on the intervals created on refactorings. This helped us to reduce utility methods related to source code on the Refactoring and ParseNode classes.<br><br>Changes on refactorings:<br><br>* [extract temporary] allow extracting entire statements without introducing an unnecessary extra statement<br>* [extract temporary] do not allow the user to extract on a smalltalk editor that does not contain a method<br>* [extract temporary] change the #apply message to return the updated source code<br>* [extract method] allow extracting expressions with multiple levels of parentheses and spaces between them<br></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></div> </blockquote></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><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 size="2" face="tahoma, sans-serif">-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> </blockquote></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></div> </blockquote></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>