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