On 17 March 2010 11:46, Lukas Renggli <renggli@gmail.com> wrote:
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?
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?
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.
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.
RPackage is explicit, it manages and knows its own contents.
Sure thing. In same way as i can write a brief description about something. But description of a subject cannot replace a subject itself. Because its missing a behavior and many other aspects.
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.
you refer to a model, which doesn't takes this into account. Sure thing, it wont work. If you remember, i told about packages having policies, when any modification of a package, such as adding or changing a method, should go through package policy verification, and only then added to package, or rejected. This is what i think will be a cool thing. This is what i could easily implement with a new model. Now think how you could do that in yours. 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..
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.
It is not practicable because its not complete. Browser usually operating only with a small subset of a package - a class and its methods. I don't see how such organization could affect the performance. 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 really doubt that, given how things like #listAtCategoryNamed: implemented. And either way, at any time, i can add an inst var which will cache classes , if i would think this is not enough. 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. And this is where we using an automated things for refactoring. But then, a performance in a mass-refactoring tools is not very relevant. -- Best regards, Igor Stasenko AKA sig.