On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote:
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 do not see how? without first class class and no string match: '* class' ? I'm curious
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.
Igor what happen when your class change shape. I do not know if it is becomed but if it is not we are in trouble.
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
Yes
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, ...).
This is what I did. Now in RB they do not deal with extensions.
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