On Thu, 17 Feb 2005 15:40:35 +0100, Alexandre Bergel <bergel at iam.unibe.ch> wrote:
> I have attached three changesets. Load SystemChangeNotification, Package.18
first and then PackageBootstrap. Then evaluate 'Package bootstrap'. All the
tests defined in PackageTest should pass.

Thanks.  It was very neat to open a proper package browser - I especially like
being able to see either a hierarchy for the whole package, or the individual
categories.
A few shallow comments:
- For anyone else trying this out, note that you have to load OmniBrowser first.
- You seem to have custom subclasses of the OB nodes for all the code elements -
OBPackageMethodNode, etc.  These mostly seem to just add items to the context
items.  I don't know the internals of OB that well, but I had the impression
this wasn't necessary; you should be able to extend the menus for a node type on
a given browser without subclassing the node class.  Colin?
- There's a lot of code in Package that's still doing the old PackageInfo stuff
of parsing category names (in fact, it makes it hard to see what you've done
because most of the class is just a copy of PackageInfo).  From what I can tell,
that's all there to support #syncFromSystem, which throws out all the "real"
package stuff and rebuilds it from the category names.  Clearly this is a
necessary step for bootstrapping, but I'd like to see it separated off and only
used there.  It should be possible, once an image has been converted from
PackageInfo to package, to keep it that way: any code that gets loaded in gets
automatically put into Package (with the package info conventions on category
names discarded).  Since Monticello is de-facto the only way packaged code gets
into or out of an image, it should be easy to set up a bottleneck to catch this
on the way in, and possibly also convert it back on the way out (by modifying
category names as appropriate).  Then you can toss the whole idea of "syncing",
which to my mind defeats the purpose of the exercise.
- I find it hard that there's no visual feedback when I move a method to another
package, and that there's no way to see all of the extension methods for a given
package.  I assume you're still working on that part of the UI?

Also: what I didn't see any evidence of so far is the kind of preload/postload
stuff that this thread was about, so I'm not sure what Stef meant when he said
that we should look at this first.  It seems to me that any work we do on that
with PackageInfo will port quite nicely to Package when it's ready.  So I don't
see any reason to wait.

Avi