10 Mar
2010
10 Mar
'10
2:12 p.m.
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