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.clem...@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.uh...@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.
