Hi Stef, i took a look on your implementation and i don't like it. :) 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. By looking at: addSelector: aSelector ofClass: aClass "Add the method to the receiver. If the class is not locally defined in that package then the method is defined as a method extension: ie extending another package. The method is not added to the class." aClass isMeta ifTrue: [(metaclassSelectors at: aClass soleInstance name asSymbol ifAbsentPut: [Set new]) add: aSelector.] ifFalse: [(classSelectors at: aClass name asSymbol ifAbsentPut: [Set new]) add: aSelector.]. This approach, from very starting, unnecessary complexifies the model, and requires a lot of glue code. 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? 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 ;) ) : 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. note, that there is no any 'methods' or 'classes' . It is just objects and names. And then you can start adding flesh on that skeleton by implementing things , like covenient adding/defining/lookup classes, methods , etc etc. 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 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? In such form, a package becomes only a view of something which already exists in a system without it. It doesn't defining a domain space - just reflecting existing one (a years-old existing system organization (classes and methods)). And thus, you will have a hard times when you would want to migrate to a new system organization, because all levers of control lying elsewhere, instead in a package itself. On 16 March 2010 18:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if     - somebody could have a look at the code     - develop a simple package browser showing class extensions (it would help me to define     a good api to walk though a package). I started to use Momo and this is why I reimplemented the class     but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far     - integration with MC     - migrating from packageInfo     - event notification     are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.