Thanks Sven! this looks good, and now also behaves same way as concating other collections (that is, the result type is the receivers' type).
Peter On Mon, Mar 06, 2017 at 10:54:32AM +0100, Sven Van Caekenberghe wrote: > 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 > >
