Hi.

> > Here's a better version of my previous two fixes for #isEmpty. It
> > includes a reimplementation of String>>keywords that takes ~2/3 the time
> > of the previous one to execute.
> The performance gain is nice: String>>keywords is probably used during
> compiling.

And during fileOut too. Actually, the first time I fixed it so it wouldn't use
#isEmpty. But it was flawed, so I decided to make a new one from scratch.

> To PositionableStream>>isEmpty: Why is it misleading to use it? Have I
> missed some discussion?

I was trying to make paste work in some text widget I was doing, and because of
the use of #isEmpty, it didn't work because #isEmpty was being used where it
shouldn't have meant "is empty"... so I asked about it (or something) and Bob
Arning posted a message from Dan Ingalls back in 1998 or so saying that Squeak
should be cleaned up regarding #isEmpty. In the interim I had reimplemented
#isEmpty so my text widget would work, but then I broke down #keywords. So I
put the old #isEmpty back, and fixed #keywords and the text stuff so they
wouldn't use #isEmpty anymore, but then #keywords was flawed because filing out
from a change set would not work, so I made a new one that works and is faster
too.

Ok. Now, the other thing is that ChangeSet>>superclassOrder: is extremely
inefficient. This method determines the order in which the class definitions
are written in the fileOut. I have a changeset about 3Mb here with 714
classes/metaclasses in it. The whole fileOut of this changeset takes ~95
seconds, but just figuring out the order in which to file out the class
definitions takes 67 seconds [Pentium III/600]!!! So I am now testing a new
version that takes less than 10 seconds. Essentially, I use Sets instead of
OrderedCollections because inclusion can be tested by hash instead of linear
search (take a look at what it does --- argh!!!).

What I had thought about it was that I'd like to split the class/metaclass list
in straight hierarchy lists and then perform superclass ordering there where it
would be easier. Or, if the classes could be put into a tree, you could go down
the tree level by level writing out the definitions of the classes that are in
the changeset as you go... hmmmm... perhaps it's even faster to start at
ProtoObject with its subclasses and start marking out the ones in the change
set as you go... something like...

File out class definitions for subclasses of nil.
File out class definitions for subclasses of subclasses of nil.
... for subclasses of subclasses of subclasses of nil...
... etc...
File out all the methods.

I do not understand yet how metaclasses would fit in here... perhaps it's the
definition of the classes, then the methods... I have to take a look at it, but
I am a bit confused by the ordering algorithm.

Andres.