Line end convention in method source

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Line end convention in method source

NorbertHartl
I had a strange effect using a method as storage. I had a list of strings that I compiled into a method. The strings were delimited by Character lf. I created this on a Mac. Saving the source and opening the same code on a linux machine changed the line endings from lf to cr.
IMHO this is a bug because I think that the content of a method should be unchanged in that case. Or are there any other reasons why this is the way it is?

thanks,

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: Line end convention in method source

Marcus Denker-4
Hi,

This is strange… do you have a way to re-create it?

it looks like a bug (or a non-wanted side effect) to me...

> On 17 Feb 2016, at 09:56, Norbert Hartl <[hidden email]> wrote:
>
> I had a strange effect using a method as storage. I had a list of strings that I compiled into a method. The strings were delimited by Character lf. I created this on a Mac. Saving the source and opening the same code on a linux machine changed the line endings from lf to cr.
> IMHO this is a bug because I think that the content of a method should be unchanged in that case. Or are there any other reasons why this is the way it is?
>
> thanks,
>
> Norbert
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Line end convention in method source

Sven Van Caekenberghe-2
But I think it is a bit dangerous to rely on a specific EOL convention being maintained in method source code. Although I agree that it should not touch the contents of constants.

You could do something (inefficient) like

^ String lf join: 'one
two
three' lines

I've done this before (to get CRLF).

> On 19 Feb 2016, at 10:32, Marcus Denker <[hidden email]> wrote:
>
> Hi,
>
> This is strange… do you have a way to re-create it?
>
> it looks like a bug (or a non-wanted side effect) to me...
>> On 17 Feb 2016, at 09:56, Norbert Hartl <[hidden email]> wrote:
>>
>> I had a strange effect using a method as storage. I had a list of strings that I compiled into a method. The strings were delimited by Character lf. I created this on a Mac. Saving the source and opening the same code on a linux machine changed the line endings from lf to cr.
>> IMHO this is a bug because I think that the content of a method should be unchanged in that case. Or are there any other reasons why this is the way it is?
>>
>> thanks,
>>
>> Norbert
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Line end convention in method source

Peter Uhnak
Or be platform-independent and store it in an array, and retrieve on demand?

MyStorage>>strings
    ^ #('string1' 'string2' 'string3' ...)

MyStorage>>stringsSeparated
    ^ self stringsSeparatedBy: String lf

MyStorage>>stringsSeparatedBy: aSeparator
    ^ self string joinUsing: aSeparator


On Fri, Feb 19, 2016 at 10:46 AM, Sven Van Caekenberghe <[hidden email]> wrote:
But I think it is a bit dangerous to rely on a specific EOL convention being maintained in method source code. Although I agree that it should not touch the contents of constants.

You could do something (inefficient) like

^ String lf join: 'one
two
three' lines

I've done this before (to get CRLF).

> On 19 Feb 2016, at 10:32, Marcus Denker <[hidden email]> wrote:
>
> Hi,
>
> This is strange… do you have a way to re-create it?
>
> it looks like a bug (or a non-wanted side effect) to me...
>> On 17 Feb 2016, at 09:56, Norbert Hartl <[hidden email]> wrote:
>>
>> I had a strange effect using a method as storage. I had a list of strings that I compiled into a method. The strings were delimited by Character lf. I created this on a Mac. Saving the source and opening the same code on a linux machine changed the line endings from lf to cr.
>> IMHO this is a bug because I think that the content of a method should be unchanged in that case. Or are there any other reasons why this is the way it is?
>>
>> thanks,
>>
>> Norbert
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Line end convention in method source

NorbertHartl
In reply to this post by Sven Van Caekenberghe-2
I didn't think about danger because it is a short term hack that will go away soon. I was just wondering because I think it is a bug.

I now compile storeString into the method which generates an ordered collection.

Norbert

> Am 19.02.2016 um 10:46 schrieb Sven Van Caekenberghe <[hidden email]>:
>
> But I think it is a bit dangerous to rely on a specific EOL convention being maintained in method source code. Although I agree that it should not touch the contents of constants.
>
> You could do something (inefficient) like
>
> ^ String lf join: 'one
> two
> three' lines
>
> I've done this before (to get CRLF).
>
>> On 19 Feb 2016, at 10:32, Marcus Denker <[hidden email]> wrote:
>>
>> Hi,
>>
>> This is strange… do you have a way to re-create it?
>>
>> it looks like a bug (or a non-wanted side effect) to me...
>>> On 17 Feb 2016, at 09:56, Norbert Hartl <[hidden email]> wrote:
>>>
>>> I had a strange effect using a method as storage. I had a list of strings that I compiled into a method. The strings were delimited by Character lf. I created this on a Mac. Saving the source and opening the same code on a linux machine changed the line endings from lf to cr.
>>> IMHO this is a bug because I think that the content of a method should be unchanged in that case. Or are there any other reasons why this is the way it is?
>>>
>>> thanks,
>>>
>>> Norbert
>>>
>>>
>>
>>
>
>