Maybe you've also run into the problem with the symbol table that had very bad performance characteristics:
http://code.google.com/p/pharo/issues/detail?id=1047 It was fixed in Pharo last summer. Adrian On Dec 25, 2009, at 22:45 , Adrian Kuhn wrote: > Stéphane Ducasse <stephane.duca...@...> writes: > >> I was wondering if it would make sense to have >> Point name >> Point class name >> both returning a symbol and not in one case a symbol and the other a >> string. > > To my understanding, the role of a symbol is to be a speed-optimized > identifier > (of either a class or method) and #'Point class' is not an > identifier but an > expression which does not evaluate faster when being a symbol. > > Also creating too many symbols might harm system performance. I > learned that > the hard way with Moose, it used to use symbols everywhere and > eventually it > would take 10 seconds to open autocompletion. So I am always > reluctant to make > too many symbols. > > --AA > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
