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 ? (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...
Peter
On Sun, Mar 05, 2017 at 04:29:39AM +0200, Igor Stasenko wrote:
Hmm.. symbols is usually treated like immutable object(s) in system. They tend to stay while rest of data changes.. This could explain why authors of this method purposedly picked to use ByteString for its species to discourage using symbols for collection manipulation(s).. Else, if you would need to change this method as well:
at: anInteger put: anObject "You cannot modify the receiver."
self errorNoModification
because base class #, implementation is going to use at:put: during concatenation.
On 4 March 2017 at 13:40, Clément Bera <bera.clement@gmail.com> wrote:
Hi,
All symbols are interned in the Symbol table. If one does (#foo , #bar , #baz) and each returned value would be a symbol, then both #foobar and #foobarbaz would be registered in the symbol table.
I would guess that's why the concatenated value is a string and not a symbol, to avoid registering many unused symbols. But maybe I am wrong.
If for your use case you need to concatenate symbols and get a symbol out of it, you can define a new method in Symbol to do what you want.
For example:
Symbol >> ,, arg ^ (self , arg) asSymbol
Then
#foo ,, #bar
Answers directly the symbol #foobar.
Best,
On Sat, Mar 4, 2017 at 11:36 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
Hi,
why is the concatenation of symbols a string?
e.g. #desc, #Name -> 'descName'
this means that I have to always wrap in parentheses and recast, or stream it, e.g.
(#desc, #Name) asSymbol -> #descName Symbol streamContents: [ :s | s << #desc; << #Name ] -> #descName
both of which introduce extraneous syntactical clutter. The technical reason seems to be ByteSymbol>>#species returning ByteString, but I have no idea why it has to be this complicated.
Thanks, Peter
-- Best regards, Igor Stasenko.