Stef, Are you perhaps running into problems with mapping category names to packages? The Dolphin approach to that is to avoid the topic: just present a list of packages and make the user pick one, after which the class/method/etc. is packaged. The resulting package system might then suffer the indignity of cyclic prerequisites, but there are ways to help the user fix that. I am not saying it is the correct solution (nor suggesting that it is not) - just reporting what Object Arts did. They got so many things *really* right that I default to trusting them.
Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Stéphane Ducasse [[email protected]] Sent: Sunday, August 01, 2010 1:39 PM To: [email protected] Subject: Re: [Pharo-project] About overlapping packages :( Ok I will have a look. My new package implementation is fast and robust now I'm just bumping into fuzzy PackageInfo semantics. Stef On Aug 1, 2010, at 5:07 PM, Schwab,Wilhelm K wrote: > 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>_______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
