On 09.03.2010, at 10:43, jaayer wrote:
The most recent version is completely string-based. The performance of the symbol-based predecessors was erratic; it would be terribly slow at first in a clean image and improve only after saving the image at least once. Even then my tests indicated that a purely string-based version would be faster. This is likely due to the initial overhead of interning symbols and then the subsequent overhead of looking them up. I did honestly prefer the #symbol syntax for naming things, but considering that the things so-named and the names themselves all begin life (from the tokenizer) as strings, it makes more sense (and requires less code) to keep them that way. It is also more portable, as we no longer need assume that Symbol is a subclass of String. I don't think this will cause issues in Squeak/Pharo code, as both systems (for now) assume #name = 'name'. Hopefully it will not cause too much trouble for Norbert.
I don't think it is a big problem. The other way round I had to check all over the place that symbols are created before requested as name at the xml classes. In gemstone it is even the case that #key->'value' creates an object of class SymbolAssociation and testing equality is checking for class identity as well (unlike isKindOf: in squeak/pharo). It took me a while to solve some of the failing tests just because of this. While my feeling tells me that symbols would be the appropriate thing to use it seems they are just to troublesome. Regarding the "shortlivedness" of a DOM the effort of converting to symbols is hard to justify.
I'm planning to incorporate the latest changes by next week. I'll start complaining if I hit another wall.
thanks for your work (and the tests!)
Norbert