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

[Phil B]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200510/507e3e75/attachment-0001.htm>