PackageDescription: MethodVersions


Method Versions

Last published: July 22, 2003 by 'dianams'

Defines 3 Classes
Extends 17 Classes

MethodVersions is seriously derivative of Method-History, but the changes are significant and I think deserve their own package.

Much assistance was gratefullly received from Florin Mateoc, especially in paring the History dictionary from a pretty fat elephant to a nifty sleek gazelle and in divining "which" SourceFileManager was really the right one and ensuring that it be the only one referred to when recording and retrieving the changes.

The idea here is to be able to look at all versions of a method back to the original in the sources and, if connected to a Store repository, the versions of the method that exist there. A menu entry "Versions" is added to the method menu in the browsers and debugger. If there have been changes to the method an interface which is the list of versions in the top pane and a differator in the bottom two panes is launched. The differator selects the loaded version of the method and it's text is displayed in the left pane of the diifferator -- the right pane will present the text of the next method selected in the right pane ready for comparison. The differator can be used for as many compares as the user wishes, and any of the methods showing in the list may be "replayed". I briefly looked at adding this functionality to the ChangeList interface, but found it so opaque for quick (or slow ;-)) penetration and surrended to the separate ListDifferator approach. There is currently a shift hack which allows the user to get a ChangeList open on the versions should that be what is desired -- this is what was offered in the Method-History parcel.

I'm not wild about what is displayed in the top (list) pane of the differator which attempts to some indication of where the code resides, but absent time stamps in the changes log, I haven't been able to manage better. Anyone with a better feel for what information is actually available for a given change is encouraged to enhance or ask me to enhance.

The heart of this package is the ChangeHistorian class. This is true in the Method-History parcel as well. In both implementations, there is a shared dictionary (History) which holds references to changes that have been made. In the MethodVersions, an IdentityDictionary is keyed by selector. The values are either an association keyed by class and having as its value an integer (which is a source pointer) or and array of such pointers; or, the values may be another IdentityDictionary keyed by class wth an integer or array of integers as their values. When there is a dictionary as a value at a given selector, it means that more than one class implementing the selector has been changed. This gives a very terse, if somewhat opaque account of where the changes reside in the changes log or sources. In the Method-History package, the History dictionary was populated with instances of a class call SourcePointerLink, which in addition to preserving the source pointer, had and instance of the change reified as a MethodDefinitionChange. This means that a lot of information is being held in the image adding to its size, sometimes significantly. The MethodDefinitionChange is still created, but at the time the versions are sought for comparison, not when they are created.

The optimum way to use this package would be to ensure that it is the first thing loaded in a bare bones image. In this case all versions of changes will be tracked for the life of the image, so long as the changes file is preserved. The History is always refreshed back to the last snapshot, when an image is launched. If the package it loaded after other packages have been loaded, the History may be populated from the changes log by running #startFromChanges. If changes have been made to base classes and a view of the original method is desired, access can be acquired by running #resolveWithSources (can take a few minutes -- really only necessary if changes have been made to base classes before the MethodVersions package is loaded).

Please feel free to improve or ask me to -- Enjoy

Diana MerryShapiro
selobr8@acm.org