Dan Ingalls wrote:
Apparently some of the new updates after modules have had their classes strangely classified. I say this because if you do a 'find...' in the left pane of a browser, they do not seem to be findable, even though they appear at the bottom of the leftmost pane.
Ok, the updates got out so fast I didn't have the time to say this in public:
There are now multiple name spaces, one per module.
So an important thing to keep in mind is that in subsequent change sets and especially updates, system categories in class definitions *have to* agree with that of the existing class, or a second class will be added in the module specified by the category. (Harvesters, in particular, keep this in mind.)
Since system categories are simulated from module path names, classes will be placed in *exactly* the module specified in the category of a class definition--even if the module doesn't exist. This is for reasonable backward compatibility.
So, new classes will be placed there obviously. But, for an existing class in a certain module, a *new class* will be created from the new class (re-) definition if it specifies a different module. This is not a bug, it is because every module has its own name space.
One could circumvent this by ignoring the category for any class already present under #(Squeak), but I don't think this would be a good thing, all things considered.
Do you know how to fix this so they can be found?
attached.
and/or warn so it doesn't happen in the future?
Umm, there is a warning for reusing class names, but they are suppressed during fileIn... suggestions?
write an update with code that will repair existing cases?
attached.
Finally, a warning: There are now (and have been) coming out updates that refactor the image. This should always be done on a non-modified, standard image.
If there are classes in improper places (ie. badly placed modules), they are in danger during refactoring. There is code to prevent this, but there are no guarantess that this will always work (although I don't see why it should happen).
Henrik