> 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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
