Explicitly only! Because package is in control and should govern all of such operations:
package remove: someclass.
how do you removing a class from a system? Right:
Smalltalk removeClassNamed: aName
so, what is wrong with that?
Nothing is wrong. It sounds great, but unfortunately we have an existing system that doesn't work like this. And big-bang changes like you propose don't work. There will be thousands of lines of code to be adapted in the image and in external packages.
How does the package know when a class is deleted from within a #doSilently: block?
this is irrelevant. Because if you build a system from a first principles, where a package is one of the key concepts in it, instead of a hollow abstraction, sure thing you taking care about all of it in proper manner.
Yes, but we don't build a new system. We fix and improve an existing one.
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).
'Elsewhere' is a key word here, which means that PackageInfo  is a view, and nothing more.
Yes, PackageInfo is a view. I am just saying that RPackage is not a view.
Another thing: your model allows only classes to be a real citizens of package. While with mine, i can export any object which belongs to a package, as long as it knows how to serialize/deserialize itself. This means that i can define named variables in scope of package, like: Â - Display, Sensor , World etc etc..
The question is if we really want to have that. You're proposal seems to try to solve too many problems: packaging, namespaces, import, export, serialization, ... RPackage aims to solve one thing only, packaging.
If you refer to things like #classes , compare mine:
classes     ^ contents select: [:object | object isBehavior and: [ object isMeta not] ]
and the old PackageInfo:
classes     ^(self systemCategories gather:         [:cat |         (SystemOrganization listAtCategoryNamed: cat)             collect: [:className | Smalltalk at: className]])                 sortBy: [:a :b | a className <= b className]
and you stating that mine will work slower?
I am not talking about PackageInfo. I think we agree that PackageInfo is not ideal. What I am saying is that Package.st is no better than PackageInfo, because it iterates over a large set of objects to select the interesting parts. That slows tools down. RPackage has a structural model and can return the classes without having to filter.
Unless you want to generate a thousands lengthy lists in your tools. But then it is impractical from either side - users can't cope with such big amounts of information.
You need to be able to generate thousands of (small) lists for classes, protocols and methods when you for example scroll through a package tree. Select a package in O2 or a category in OB and scroll down using the down arrow to see what I mean. Lukas -- Lukas Renggli http://www.lukas-renggli.ch