What are MC2 slices
Last updated at 2:50 pm UTC on 24 June 2007
By Colin Putney:
Version history in Monticello 2 isnít tied to packages. Instead, it introduces the concept of slices.
A slice is, quite simply, a set of elements - an arbitrary slice of the code in the image. We can define several different kinds of slices:
In Squeak, we can use PackageInfoSlice to get packages identical to those used by Monticello 1. In other dialects weíd create slices to interface with the native packaging code - PackageSlice and BundleSlice in VisualWorks for example.
A ChangeSet also defines an interesting slice of the image, and by implementing ChangeSetSlice, we can make them versionable and mergeable, just like packages. Iím really looking forward to this one, actually. Itíll make the lives of package maintainers easier, since contributors can just send them change sets rather than full packages.
Lately, Iíve become interested in combining Monticello with Spoon. One of the keys to that integration would be to create a NaiadSlice. This would define a slice based on the elements involved in executing a given Smalltalk expression.
Probably the simplest kind of slice is defined with a collection of elements. At some point, Iíd like to create a UI for easily creating an ExplicitSlice. Iím imagining a window which lists the contents of the slice, and accepts new elements via drag and drop from OmniBrowser. For now, though, ExplicitSlices can be created pogrammatically, and are really handy for testing.
Although theyíre probably not useful for everyday development, there are other kinds of slice one might want. A FileOutSlice would enumerate all the elements in a particular chunk file. We could do the same thing with the sources and changes files. We could create a slice that scanned the changes file and included all elements modified between a pair of snapshot markers. When demoing Monticello 2 I sometimes joke about creating a slice that includes all the elements that match a given rewrite rule. I donít know how useful it would be, but why not?
For the moment, Iíve only implemented ExplicitSlice and PackageInfoSlice, since theyíre needed to acheive feature parity with Monticello 1.
It's true that we don't commit slices to the repository, yes. But slices don't really "contain" elements, they just enumerate them. (MDExplicitSlice is the obvious exception to this, but it's meant mainly for testing.) The role of a slice is to divide the image into two parts: the parts that belong to the slice and the parts that don't. MDPackageInfoSlice does this on the basis of a PackageInfo instance - anything in the package belongs to the slice, anything not in the package does not. The plan is to have other types of slices as well, based on ChangeSets, RefactoringEnvironments, and anything else that seems interesting.
Also, elements aren't committed to the repository per se, but only as part of an MDVersion.
When a snapshot is created, a slice decides which methods should be part of it, and the resulting snapshot describes the state of those methods and their versioning history.