Hi Ben! I answer between lines. If the discussion continues maybe we should move to another thread also ^^.
El sáb., 6 de jun. de 2015 a la(s) 12:39 p. m., Ben Coman < [email protected]> escribió: > On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito > <[email protected]> wrote: > > Actually we just want to have a kind of split in: > > > > - essential > > - non-essential > > I guess you have scripts outside the image to shrink the image and > then bootstrap it. However these are not necessarily visible to everyone and I am wondering once the bootstrap goal is achieved you > will handle the entropy of ongoing development by many others > accidentally introducing dependencies that breaks the bootstrap? > Well no. I try to not do that. Currently what I have working is: - a metacello configuration describing the packages+versions that will be part of the built kernel - a simple script that will create the initial objects of an image before class creation (e.g., create Smalltalk, initialize the symbol table, etc). I want this guy to be the smallest as possible to avoid what you describe above - a script to initialize the image after class creation. e.g., create the first process, and execute some class side initialize. Then again, the ad-hoc bootstrap scripts try to be minimal to avoid being impacted. Of course they could be impacted by changes of APIs, but I think it is still controllable in the size of the scripts :). And then, that is why I try to push as many "modularity" concerns to Pharo itself, to keep these scripts small. > > Also what I have seen is classes being moved out of their current > packaging (sorry I forget the details, but I think it was moved out of > System) into a new top-level package, which I think loses something in > structure and might pollute the top-level packages. > Yes, mea culpa there. Some times when extracting classes from one package I didn't put the new package under the System-* or whatever top level package. However, I believe also that the agreement on what are the top-level packages is kind of implicit and obscure to me. I remember some discussions in the list with the Alt browser from Thierry using the idea of top level packages, and others talking about the navigation of the system. I check the latest Pharo Image and I found: - AST (should be system?) - Announcements (should be system?) - Collections (should be system?) - Files (should be system?) - Networking (should be system?) ... And then if we check what is inside the System top-level package today I'd say it is a sack full of random things, with no evident criteria. So maybe we should discuss and agree on how to name packages and top-level packages! > So considering the recent discussion of package tags, I wonder if > somehow we could have a "Bootstrap" tag and realtime critics that > complain if Bootstrap-tagged-class references any > non-Bootstrap-tagged-class. There might even be several levels of > Bootstrap tags. This would improve ongoing visibility of the > bootstrap structure and help the rest of us to not shoot it in the > foot. v > I wonder also if tags might also be extended to method protocols, so > you can have a method with the "accessors" tag and also the > "bootstrap" tag, so that even a Bootstrap-tagged-class can be further > minimised by the methods it needs during bootstrap. Otherwise I guess > to minimise the methods in a Bootstrap-tagged-class, later extension > by another package could not add methods to the "accessors" protocol. That would be amazing if I could add meta-data to packages to only install specific classes. Because we could keep a coarser granularity of packages while keeping the bootstrap small. However, the problem is that you cannot predict what classes/methods the bootstrap will use. So far, I'm using the class builder to build classes in the bootstrap. In such way, I ensure that all classes that I create will honor the same invariants as a normal class and I don't have to duplicate the creation code :). That means that we can change the internals of the class builder as long as we don't change the API + preconditions and the bootstrap will continue working. Guille
