HI guys,
I have this difference: Pharo: 'aaa' asSymbol -> #aaa #aaa = 'aaa' -> true GemStone 'aaa' asSymbol -> #'aaa'
#aaa = 'aaa' -> falseThat doesn't look like a big difference, but it is for me! One of the reasons is that I have several dictionaries in which I have strings which are stored as symbols...this is usually to save space, make the lookup faster or some other reason. But then, at the time for searching in the dict my object is a string... in pharo it worked, but here of course the lookup fails. So yes, I have send as #asSymbol to the key before searching it. But...that could be many places in code and maybe a bit hard to find.
So I wonder...anyway had a similar problem? What I was thinking is to create a subclass of #SymbolKeyValueDictionary that implements #at: sending #asSymbol to the argument...or a another subclass that instead of using the normal #= does a bit of magic to make symbols and strings #=.
BTW....now that we are discussing about this...SymbolKeyValueDictionary and StringKeyValueDictionary are more performant than KeyValueDictionary when the keys are either string or symbols right? I guess that's the reason of their existence...but if you can confirm, that would be appreciated.
Thanks! Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Am 09.12.2013 02:46, schrieb Mariano Martinez Peck:
> HI guys, > > I have this difference: > > Pharo: > > 'aaa' asSymbol -> #aaa > #aaa = 'aaa' -> true This seems to be a very strange result Marten _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
I had the same problem during my first
steps.
Here is what Dale wrote me at that time: " This is another case where code has to change ... Pharo does not conform to the ANSI standard for String and Symbol comparison (and GemStone does conform). In Pharo Strings and Symbols can be used interchangeably and that wreaks havoc for GemStone ... " He also mentioned that the "usual" Dictionary is usually performant enough and Strings for comparison are save under Gemstone. Sebastian Am 08.12.2013 22:09, schrieb [hidden email]: Am 09.12.2013 02:46, schrieb Mariano Martinez Peck:HI guys, I have this difference: Pharo: 'aaa' asSymbol -> #aaa #aaa = 'aaa' -> trueThis seems to be a very strange result Marten _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Mariano Martinez Peck
On Mon, Dec 9, 2013 at 2:46 AM, Mariano Martinez Peck
<[hidden email]> wrote: > HI guys, > > I have this difference: > > Pharo: > > 'aaa' asSymbol -> #aaa > #aaa = 'aaa' -> true > > GemStone > > 'aaa' asSymbol -> #'aaa' > #aaa = 'aaa' -> false > > That doesn't look like a big difference, but it is for me! One of the > reasons is that I have several dictionaries in which I have strings which > are stored as symbols...this is usually to save space, make the lookup > faster or some other reason. Did you actuall benchmark this? #asSymbol does a look up in the symbol dictionary so if anything I would expected it to make your look up slower. And you fill up the symbol dictionary. Cheers Philippe _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by marten
Am 09.12.13 07:09, schrieb [hidden email]:
> > Pharo: > > 'aaa' asSymbol -> #aaa > #aaa = 'aaa' -> true > This seems to be a very strange result > > Marten Hi Marten, that also was my first thought. But thinking about it, the difference in class between a Symbol and a String is quite technical, so you can argue that #aaa and 'aaa' are equal. They represent the same sequence of characters, even if, technically, a Symbol is only a unique name for an entry in some special list. Still this behavior is not the default outside of Pharo, and as Dale says, it's not standards compliant. So Mariano, I guess you should try and find another solution. I guess neither String nor Symbol are the best possible choices as Dictionary keys if you want to do fast and *unique* lookups, even if that sounds strange for Symbols... What exactly was your intention for Symbols? I guess it was guaranteed uniqueness, right? Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:[hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Mariano,
having/handling one and the same String instance can be achieved by using CanonicalStringDictionary and/or CanonStringDict Maybe you should have a look into their class comments. Sebastian Am 09.12.2013 02:05, schrieb [hidden email]: Am 09.12.13 07:09, schrieb [hidden email]: _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by SebastianHC
On 09 Dec 2013, at 07:50, Sebastian Heidbrink <[hidden email]> wrote: > " This is another case where code has to change ... Pharo does not conform to the ANSI standard for String and Symbol comparison (and GemStone does conform). I absolutely agree. We take care not to mix symbols or strings in our code, even though that works in Pharo. And yes, that occasionally leads to bugs, but I would prefer Pharo to move to make Symbols not equal to Strings. Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |