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 < btc@openinworld.com> escribió:
On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito <guillermopolito@gmail.com> 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