On Sep 18, 2005, at 12:53 PM, Andreas Raab wrote:
I do think that using a Squeak package with dependencies, or alternatively just changing a Configuration to have a load strategy more like a package with dependencies, would be a good idea. When I recently tried updating a 3.9a image through a few configuration steps, it was bad enough that it took as long as it did, but it was awful that it stopped to ask me about loading over a modified package many times during the process - so I couldn't just walk away. This wouldn't happen if MC's multi- package-load mechanism were used instead of explicit ordering. It would also mean you wouldn't (usually) have to think about package ordering yourself. So it should speed up the process for everyone.
Please say more about this, since it's been a while that I have used dependencies in MC at all. About load strategies: I don't know what strategy MC uses but unless it gets this right every single time (which I doubt) having configurations is vastly advantageous. Usually, I have a "master configuration" (for a project like Tweak) which lists the fifty or so packages in what I consider "load order", e.g., a unique order for loading the packages that includes eventual dependencies. If I post a new configuration I simply "update" the old oonfiguration from either image or packages and post it. It's a very simple process but if there's any need I can re-order the packages for that specific post.
Let's say I have two packages, A and B. I have a new configuration in which these two packages have exchanged methods: one method from A has moved to B, and one method from B has moved to A. I try to load that configuration. Either load order is equivalent, but let's say that we've specified that the order is A, B.
What happens is this: first A is loaded, taking one method from B and losing one method itself. Because it took a method from B, B is now marked as being modified. Next, B is loaded, but it has a modified flag, and so the user is asked whether it's ok to ignore those modifications. This is confusing, since the user never has modified B. It's also irritating because the load can't proceed unsupervised.
Ok, now a more complicated scenario: A has added a Foo class and a BarSub class. B has added a FooSub class and a Bar class. FooSub is a subclass of Foo, and BarSub is a subclass of Bar. This is admittedly contrived, and arguably bad design, but there's no sequential load order that will work for these two packages.
Both of these cases are solved by simply asking MC to load or merge the two packages together, rather than asking it to load them sequentially. The load strategy it uses is very simple: a superclass always needs to be loaded before its subclasses, and a class always needs to be loaded before its methods. Additions are always done before removals, and removals are done with the inverse rules (first remove methods, then classes, then superclasses).
What you don't get to do in that case is specify anything about the load order yourself. I think the cases where specifying this is necessary are going to be very rare, but certainly they will happen. That's what the update stream is useful for: simply put two configurations in (one of them, maybe, with only a single package) to ensure that loads happen in the correct sequence. This should only be needed for delicate migrations, I don't think it should ever be needed for every time a group of packages is loaded together.
Avi