Here is a concrete proposal:
https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol-concatenation-results-in-a-Symbol-not-a-String
This gives the following assertions:
"Concatenating 2 symbols results in abother symbol"
self assert: (#foo , #bar) == #foobar.
"Concatenating the empty symbol does not change a symbol"
self assert: (#foo, emptySymbol) == #foo.
self assert: (emptySymbol, #foo) == #foo.
"Strings and symbols can still be mixed, the receiver determines the
result type"
"Symbol receiver gives symbol result"
self assert: (#foo , 'bar') == #foobar.
"String receiver gives string result"
self deny: ('foo' , #bar) == #foobar.
self assert: ('foo' , #bar) equals: #foobar.
self assert: ('foo' , #bar) equals: 'foobar'.
> On 5 Mar 2017, at 19:53, Martin McClure <mar...@hand2mouse.com> wrote:
>
> On 03/05/2017 03:01 AM, Sven Van Caekenberghe wrote:
>> I also think that allowing concatenation on Symbols does not violate their
>> immutability contract.
>>
>> As a thought experiment, what could be the problem with adding
>>
>> Symbol >> , arg
>> ^ (self , arg) asSymbol
>>
>> ?
>>
>
> Aside from the infinite recursion (I suspect you meant super rather than
> self) :-) , I wouldn't have any problem with that.
>
>>
>> (I have found the original issue raised annoying as well)
>>
>>
>>> On 5 Mar 2017, at 11:35, Peter Uhnak <i.uh...@gmail.com>
>>> wrote:
>>>
>>> I don't need (or want) to mutate the receiver. Actually I thought that
>>> String is also immutable.
>>> $, could just return a new symbol instance instead. Concating symbols is
>>> quite practical for metaprogramming, as most things are named with symbols
>>> and compare by identity...
>>>
> Somewhat unfortunately, imho, Smalltalk Strings are mutable. I've not seen
> this feature used often, except by internal operations that could just as
> well be using a CharacterBuffer or whatever would replace String as the
> mutable thing if you made String immutable.
>
> Regards,
>
> -Martin
