Maybe I have no clue about your problem, or maybe I am in complete ignorance and denial about my own problems :) With that caveat, here is what I *think* has been working for me. To illustrate it, let's rewind to when Pharo was just getting started and I was just starting to move away from Windows. In my Dolphin image are packages with names like HPViridia and DatexCapnomac. The names match physiologic monitors, but that's not really important. What is important is that once I got a handle on PackageInfo, I started naming things like this as Recordkeeper-monitors-DatexCapnomac Recordkeeper-monitors-HPViridia Saving the one package called Recordkeeper then captures all of the infrastructure, device interfaces, and GUI (the latter being largely vapor right now). There are 28 sub-packages. Once you create a new sub-package, you can do things like aClass withAllSubclasses do:[ :each | each category:'ThisAndThat-NewSubpackage' ]. to move things to it. Two other packages, Studies and Hardware, have growing lists of sub-packages. AFAIK, package names are case-sensitive, with one exception: loose methods. PackageInfo abuses method categories to package these methods. Anything like *Recordkeeper-monitors-DatexCapnomac will include methods in the named package. I doubt it will work if there are two package names differing only by case, so it can be confusing. What I do is scan my image for methods that I wrote and have not claimed ownership of the containing package. Looking at the extension methods in the MC browser is one way to do that; I have code in Migrate that has saved me from myself on several occasions. HTH. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Damien Pollet [damien.pollet@gmail.com] Sent: Friday, August 12, 2011 5:32 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] splitting MC packages On 12 August 2011 22:21, Lukas Renggli <renggli@gmail.com> wrote:
The only solution is to stick with consistent and well though package name scheme. Not the only possible naming strategy, but the one we developed for Seaside works pretty well: http://code.google.com/p/seaside/wiki/PackageNaming
I know about these conventions, but how do I proceed towards them? :) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet