[Cuis-dev] [ChangeSet] source code intervals + changes on refactorings

[Nicolas Cellier]

Can you represent empty ranges?

For example,
(5,5) could be empty (marking a position before or after 5th character -
your choice)
(5,6) a one character range (from left to right)
(5,4) too (from right to left).

Le lun. 11 mai 2020 à 01:22, Phil B via Cuis-dev <cuis-dev at lists.cuis.st> a
écrit :

> Luciano,
>
> 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 #,.
>
> Thanks,
> Phil
>
> On Sun, May 10, 2020 at 4:38 PM Luciano Notarfrancesco <luchiano at gmail.com>
> wrote:
>
>> 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.
>>
>> On Mon, 11 May 2020 at 2:57 AM, Phil B via Cuis-dev <
>> cuis-dev at lists.cuis.st> wrote:
>>
>>> Hernan,
>>>
>>> OK, I'll hang back and see how yours evolves.  Here's what I'm thinking
>>> would address my needs:
>>>
>>> Range:
>>> start and end are both integers
>>> count is implicit and either 1 or -1 (if start<end, it's 1.. otherwise
>>> -1)
>>> Provide #asInterval for infrequent use cases where you need the extra
>>> flexibility
>>>
>>> SourceCodeRange:
>>> 0<start<=end
>>> Mostly used as a container for start and end (i.e. need getters)
>>> Next most common use is simple enumeration (esp #do:, #withIndexDo:,
>>> #reverseDo: , #select:, #collect: and #with:* variants)
>>>
>>> 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)
>>>
>>> Thanks,
>>> Phil
>>>
>>> On Sun, May 10, 2020 at 3:17 PM Hernan Wilkinson <
>>> hernan.wilkinson at 10pines.com> wrote:
>>>
>>>> Hi Phil,
>>>>  great observation!
>>>>  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.
>>>>
>>>> Hernan.
>>>>
>>>> On Sun, May 10, 2020 at 3:53 PM Phil B via Cuis-dev <
>>>> cuis-dev at lists.cuis.st> wrote:
>>>>
>>>>> Actually, Object->Range->SourceCodeRange probably makes more sense.
>>>>> Non-Interval ranges are useful for things beyond source code.
>>>>>
>>>>> On Sun, May 10, 2020 at 2:37 PM Phil B <pbpublist at gmail.com> wrote:
>>>>>
>>>>>> Hi Nahuel,
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Thanks,
>>>>>> Phil
>>>>>>
>>>>>> On Sun, May 10, 2020 at 2:24 PM Nahuel Garbezza via Cuis-dev <
>>>>>> cuis-dev at lists.cuis.st> wrote:
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> I'm attaching a changeset (+ tests changeset) with the following:
>>>>>>>
>>>>>>> Main changes:
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Changes on refactorings:
>>>>>>>
>>>>>>> * [extract temporary] allow extracting entire statements without
>>>>>>> introducing an unnecessary extra statement
>>>>>>> * [extract temporary] do not allow the user to extract on a
>>>>>>> smalltalk editor that does not contain a method
>>>>>>> * [extract temporary] change the #apply message to return the
>>>>>>> updated source code
>>>>>>> * [extract method] allow extracting expressions with multiple levels
>>>>>>> of parentheses and spaces between them
>>>>>>> --
>>>>>>> Cuis-dev mailing list
>>>>>>> Cuis-dev at lists.cuis.st
>>>>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>>>>
>>>>>> --
>>>>> Cuis-dev mailing list
>>>>> Cuis-dev at lists.cuis.st
>>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
>>>> *Phone: +54-011*-4893-2057
>>>> *Twitter: @HernanWilkinson*
>>>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>>>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>>>
>>> --
>>> Cuis-dev mailing list
>>> Cuis-dev at lists.cuis.st
>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>
>> --
> 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/20200511/ed6e2267/attachment.htm>