On 6 Mar 2017, at 14:12, Ben Coman <btc@openinworld.com> wrote:
On Mon, Mar 6, 2017 at 5:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Here is a concrete proposal:
https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol-concatenation-resul...
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'.
Those last two seem contradictory.
No, Symbols and String can be used interchangeably in Pharo in lots of contexts. Particularly when comparing them, it makes no difference, all the following are/have always been true, independent of this change: #foo = 'foo' 'foo' = #foo #foo = #foo 'foo' = 'foo' But maybe it is a bit confusing with an extra comment.
cheers -ben
On 5 Mar 2017, at 19:53, Martin McClure <martin@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.uhnak@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