Igor Stasenko writes: > 2008/11/11 <[EMAIL PROTECTED]>: > > Stéphane Ducasse writes: > > > > > > Overrides are still something that we should avoid as much as possible. > > > > It's always possible to avoid overrides by having your own branch of a > > package. Exupery does that for VMMaker. That works with MC 1.x's > > merging, and allows it to track who's changed what to make it easier > > to follow downstream changes. > > > > It may work for VMMaker (because it is quite uncommon thing), but in > broader range it will introduce even more problems. > Going with your doctrine, there can be 10 developers, each forced to > maintain own version of some basic package with own overrides. > Now, if someone would want to use all 10 projects in single image, he > will have to deal with 10 different versions of same package. > The brave soul can go through all 10 versions, spend week or two > merging them into common base. > But i don't think he would want to repeat it over and over again, in > case he wants to update one of 10 packages to new version, where some > bugs fixed or new features added.
In the case you describe you're better off using separate MC packages. You'd build your own image by merging each of the 10 developers changes together to make your own version. You're better off because MC will alert you if two of the package versions change the same method. If the changes in the separate package versions do not change the same methods then there will be no conflicts and no trouble merging. Using overrides, you're on your own tracking down conflicting changes and the only notification you'll get is the bugs produced. If one of the packages is updated, then with MC all you need to do is merge it in, MC will figure out if the new changes in that package conflict with something else. That's why I now maintain my own VMMaker packages instead of using overrides or change sets. The VMMaker base does change and sometimes methods I've changed change underneath me. It's too easy to badly break the VM trying to manage merging without utilising MCs capabilities and tracking down the breakage without decent tool support is very painful. I've done it with VMMaker before MC. I do use overrides if I need to change a single method in another package but even there I'd be tempted to keep the override in a separate override package to make them easier to find and to limit such overrides to optional functionality so users are not forced to use the override. There is one such override in Exupery itself. Bryce _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
