On Mar 17, 2010, at 11:52 AM, Igor Stasenko wrote:
Sorry, i was felt like you are at stage of 'making a first-class packages'.
this is a first class package but not a module system nor a namespace. Stef
I understand that we going slowly to that, i just wanted to be sure that you doing right thing :) Sure, if RPackage is just an improved implementation of PackageInfo , i see nothing wrong with that.
Thanks for listening my rants. :)
On 17 March 2010 12:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Explicitly only! Because package is in control and should govern all of such operations:
package remove: someclass.
in my first implementation I got package removeClassFromSystem:....
but it implies too much changes. So the goal is now. Let us have real Package objects, support the transition with PackageInfo, support MC and do the next steps when the next steps is needed.
how do you removing a class from a system? Right:
Smalltalk removeClassNamed: aName
so, what is wrong with that?
How does the package know when a class is deleted from within a #doSilently: block?
this is irrelevant. Because if you build a system from a first principles, where a package is one of the key concepts in it, instead of a hollow abstraction, sure thing you taking care about all of it in proper manner.
but there are more urgent things to fix: network and others. So let us be incremental.
RPackage is explicit, it manages and knows its own contents.
Sure thing. In same way as i can write a brief description about something. But description of a subject cannot replace a subject itself. Because its missing a behavior and many other aspects.
the behavior of RPackage is to let know if a class is extended, which are its participants.
you refer to a model, which doesn't takes this into account. Sure thing, it wont work. If you remember, i told about packages having policies, when any modification of a package, such as adding or changing a method, should go through package policy verification, and only then added to package, or rejected. This is what i think will be a cool thing. This is what i could easily implement with a new model. Now think how you could do that in yours.
RPackage is not a namespace nor an hyper cool package system. It is a simple replacement of the bad packageInfo hack. Now just making sure replacement will take us a lot of energy and we will do it.
Another thing: your model allows only classes to be a real citizens of package. While with mine, i can export any object which belongs to a package, as long as it knows how to serialize/deserialize itself. This means that i can define named variables in scope of package, like: - Display, Sensor , World etc etc..
Good but this is not the purpose of RPackage. We need a good serializer in the future too.
It is not practicable because its not complete. Browser usually operating only with a small subset of a package - a class and its methods. I don't see how such organization could affect the performance.
If you refer to things like #classes , compare mine:
classes ^ contents select: [:object | object isBehavior and: [ object isMeta not] ]
and the old PackageInfo:
classes ^(self systemCategories gather: [:cat | (SystemOrganization listAtCategoryNamed: cat) collect: [:className | Smalltalk at: className]]) sortBy: [:a :b | a className <= b className]
and you stating that mine will work slower? I really doubt that, given how things like #listAtCategoryNamed: implemented.
We are not talking about the old packageInfo
In RPackage classes ^ definedClasses
:)
Unless you want to generate a thousands lengthy lists in your tools. But then it is impractical from either side - users can't cope with such big amounts of information. And this is where we using an automated things for refactoring. But then, a performance in a mass-refactoring tools is not very relevant.
It is with Moose PackageInfo nearly killed us we have to build a cache that takes 2 or 3 min to build before being able to work.
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