Stef, Coming from Dolphin, I have been surprised at how few packaging problems I (appear?) to have had in Pharo. One of the great terrors<g> that enters the life of each Dolphin newbie is the dreaded "cyclic dependencies" error. The truth is that it is not a big deal: save the image and figure it out after you get some coffee. However, it sure seems awful the first few times the system refuses to save a package.
Dolphin uses concrete packages; classes, methods and other objects belong to a package. Non-class objects (methods, view resources) by default belong to the same package as the associated class, but they can be placed elsewhere. Packages are explicitly created by the user and then are separately populated. I was generally shocked at how much work both Dolphin and Pharo users were willing to do in saving and loading packages. Over time, Dolphin became fairly adept at loading prerequisite packages, so things got easier. However, the readers here (for whom I have great respect) mystify me - or I am missing something about Monticello. I responded by "porting" a tool called Migrate that I wrote early on for Dolphin. Dolphin's package manager was fussy about loading things in the correct order, and I had no patience for loading 100+ packages with menu commands for each. Like I said, it improve over time to make Migrate less important in Dolphin, but something like it was essential to me in Pharo. Attached is a .mcz for Migrate-Core, relevant perhaps for two reasons. First, the fact that I exploit the ability to make a package called Migrate and then dash off a Migrate-Core that (hopefully) has just what I want to make public and nothing else. Second, it might give you some ideas about what a package system should do. My code is managed by a class called GatorAid that is derived from Migrate, and other users would presumably do the same thing: subclass, override a couple of methods, and follow the instructions (mostly in the Migrate class comment and some method comments), such as they are. In short, it helps look for code that I wrote and have not yet claimed ownership by telling Migrate I want to save it; it makes saving all packages I have asked it to save a one-step operation; it helps with building a new image. Perhaps the place to start is to have a quick look and to let me know if you have any questions. Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Stéphane Ducasse [[email protected]] Sent: Saturday, July 31, 2010 11:19 AM To: [email protected] Subject: Re: [Pharo-project] About overlapping packages :( > sounds tricky. at the very least add a checker to a menu somewhere so > we can start to use it. I will do that. > You wouldn't need to that deeply integrate it > in the first instance... > > do you need to match the existing semantics exactly? I don't think > it's good that we can get into these situations. Perhaps we should > prevent them being able to be created in the first place, rather than > deal with them once they overlap. It will change the flow: we will not be able to create a new subpackage Foo-Core (if Foo is already created) , but will have to start delete the top package. Stef _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Migrate-Core-BillSchwab.1.mcz
Description: Migrate-Core-BillSchwab.1.mcz
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
