Another problem with the current fileout format

Stephane Ducasse ducasse at iam.unibe.ch
Sun Jun 29 09:18:59 UTC 2003


Hi

I just want to report the difficulties we experienced with alex when he 
built a tool to split changesets in part.

Our problem was that we had 3.5 complaint changeset and that we wanted 
to load them in 3.6alpha in which class had
been removed in parallel. So alex built a splitter that given a set of 
removals and a changeset generates a new changeset and a set of 
changesets for each of the removals. So perfect.

Now the problem is that a lot of information in the file is done by 
side effect or do-its: they act as holes in the analysis.

So it would be better to have explicit representation in the file out 
for those things.
For example having objects on top of which we could build real tools.
Note that the examples below are not right I just want to give the idea:

	RenamedCategory on: #MyClass from: #myOldComment to: #myNewComment

	RenamedClass oldClassNamed: #MyOldClassName newClass: 
#MyCoolNewClassName
	vs.
	'Smalltalk renamedClass: MyOldClassName into: MyCoolNewClassName'


	RemoveClass classNamed: #MyOldClassName
vs.
	'Smalltalk removeClassNamed: #MyOldClassName'

With the current version we have to interpret the string to get a 
meaning, with the solution
you get an object you can manipulate.

This kind of explicit representation would work well for class 
definition, Pool Definition, Class initialization too this means that 
we could load code without executing it and this would support all 
kinds of cool tools. Note that this was one of the idea behind the file 
format of Ginsu.

Does anybody got the same problem? I guess that les got that too when 
working on his analysis tool.
Avi how do you manage these annoying string in CVS? Just as string I 
imagine but this means that we cannot
really do too much.

Stef



More information about the Squeak-dev mailing list