It tries to work with methods and classes through symbolic names.. and you immediately end up with gemmorage of a need to keep separate 'core' and 'extension' , 'meta' and 'instance-side' methods in your model.
Yes, that's what I suggested, merge the extension and core dictionaries.
I don't know what is the purpose of making a package to be a dead piece of flesh, which reflects own organization by using symbols, instead of real objects? Who are you trying to deceive with that?
Incremental development. Separation of concerns. If the package would contain the real classes and real methods one had to change (literally) thousands of places in the system.
If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at it?). My concepts is simple and object-oriented (instead of symbolic-names oriented ;) ) :
Where?
If we take a most abstract and stripped down concept then, in order to define a package, we need just two things: - a set of objects , which belong to that package - and a namespace (name->object), where name is a symbol and object is one of the objects, which belong to package.
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
But if you don't that , you model will remain a piece of flesh, without skeleton - it can't move , it can only lie on the ground and rot :)
I suggested Stef to look at the environments in the refactoring engine. They are a proven implementation for more than 10 years, they work very efficiently with numerous GUIs (OB, VisualWorks, VisualAge), and have been applied in many different scenarios (introspection, reflection, refactorings, changes, lint, virtual code, ...).
I don't understand, why to not work with actual objects, instead of names? Please enlighten me, why you want to refer to objects indirectly and leaving to somethings else in the system to decide how these names turned into a real objects. What is the benefit of having such indirect model?
What would a method object refer to other than its class and its selector? Is the introduction of another layer of objects that duplicates Class, PseudoClass, MCClassDefinition, RBClass and CompiledMethod, MethodReference, MCMethodDefinition, RBMethod reasonable? Remember, this is just the internal implementation. I agree that to the outside a package should be represented using dedicated objects. Lukas -- Lukas Renggli http://www.lukas-renggli.ch