On Mar 17, 2010, at 8:32 AM, Igor Stasenko wrote:
Hi Stef,
i took a look on your implementation and i don't like it. :)
Ok fair My first implementation was holding classes and objects and people did not like it either.
It tries to work with methods and classes through symbolic names..
The first implementation was only holding classes and compiled methods/methodreferences and the problems is that you cannot reason about off-line system. Lukas told me ok this is not good because of that. Look at RBEnvironment. So I rewrote everything 3 times. So I'm started to get bored.
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?
Off image package manipulation.
If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at it?).
Now where is the code? What is the cost to find all the extendingClasses, if a method is included in a packages, classes extensions, how do we hook event for classremoval, classaddition, without raising multiple times the same.
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?
We could create package and manipulate them even if they are not in the image.
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)).
Exactly. But if you want to introduce Package then a method should know its package (which I did in my first implementation).
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.
Did not get this one.
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project