If the package would contain the real classes and real methods one had to change (literally) thousands of places in the system.
Hmm.. why is that? Currently everything in image is centered mainly around classes and methods & categories. And only a little around packages.
How does the package know when a class is deleted? How does the package know when a class is deleted from within a #doSilently: block?
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
As i said, it doesn't implements a new model, but a different view on existing one.
RPackage does not implement a different view: PackageInfo is implicit, it takes all information from elsewhere (category and protocol names). RPackage is explicit, it manages and knows its own contents.
Err, what you mean by that? If a 'method object' is a method, then it should behave like a method - conform on a method's protocol. Isnt?
The question is if you really want to store the real thing (compiled method)? RPackage chose to store a reference, because the real thing can easily and quickly be looked up. Package.st stores compiled methods in a large IdentitySet. Recompiling a method means that it need to be removed and re-added whenever something changes in the system. Somebody doing something in a #doSilently: block will immediately screw up your complete package model, because you suddenly miss methods or have different methods that are actually the same. Package.st does not seem practicable to build an efficient GUI. Having to iterate over the complete package contents to find certain elements is deadly to a responsive GUI. Getting the classes and methods must be a fast operation (ideally constant time) that does not depend on the number of elements in the package and the number of other packages. RPackage aims to answer questions a GUI might have quickly. Lukas -- Lukas Renggli http://www.lukas-renggli.ch