On 17 March 2010 10:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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.
It sounds like you can reason about contents of an image file if you open it in a text editor or hex dump.
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.
So, looks like i am little late in the game.. Too bad.
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.
I fail to see how this is relevant to a in-image representation. I can choose any file-out/in format i want - binary, xml, .st , whatever... So, i really don't understand what you talking about 'off-line' here.
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?
Strange, i thought i shown it before.. i could send it to you if you want. I remember i presented most of my ideas & concerns about this couple months ago, and we did talked about it.
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.
In a properly implemented system it will be same or less. Because model is same, since you refer to same object(s), having same structural organization. So why it should be any slower?
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.
same as above about 'offline'... what you mean by manipulating something which lives and having a flesh only if it runs inside an 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).
Indeed, or reversely - a package knows what methods belonging to it. Take a look at ClassOrganizer it using similar approach. A method doesn't knows to what category it belongs to. But still, tools are able to determine that. Except that , again a ClassOrganizer refers to methods indirectly, through 'selectors', like selectors have anything to do with behavior , which is any compiled method holding. Or maybe this is what you talking about 'manipulating offline'? You can file out class name and selectors it contains. Now you can manipulate with these names... for no purpose, because you missing a key thing which makes all of these names reason to exist - a behavior and data:) We saying 'each method of class belongs to a certain category'. This means that there are relation between category name and a method. The question is where to put that relation - you can either add a 'category' or 'categories' field to a compiled method and you done or start building a mess.
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.
ClassOrganizer is your guide. ;)
-- Best regards, Igor Stasenko AKA sig.