Monticello and overwriting a selector temporary

Philippe Marschall philippe.marschall at gmail.com
Thu May 24 11:43:57 UTC 2007


Bert is right, resist the temptation. Don't do it. It will bite you later on.

Cheers
Philippe


2007/5/24, Norbert Hartl <norbert at hartl.name>:
> On Thu, 2007-05-24 at 12:56 +0200, Bert Freudenberg wrote:
> > On May 24, 2007, at 12:29 , Norbert Hartl wrote:
> >
> > >
> > >>
> > >> There is another practice which is far from "best". It's only
> > >> slightly less evil than modifying other packages. It causes headaches
> > >> in the long run. It depends on the Monticello and PackageInfo
> > >> version. You should not use it but stick to the best practice. And
> > >> definitely do not use it for anything you want to share. You have
> > >> been warned. This practice is called "overrides", and works by moving
> > >> your method into a "*mymodule-override" category. This lets
> > >> Monticello know this is a temporary override and it will try to
> > >> restore the original method when you remove it from your package - it
> > >> relies on a proper version history in the changes file for that. This
> > >> is highly unreliable in most but the very simplest cases. Did I
> > >> mention you should not use it, unless you *really* know what you're
> > >> doing? And don't come back and complain ;)
> > >>
> > > Oh, well, I can read between the lines that this is a good approach
> > > to do :) All I can understand is that in my case it only can do
> > > less harmful changes. I haven't tried but it looks like _exactly_
> > > what I was looking for. And I will convince a lot of other people
> > > to use it, too. :))
> >
> > Even with the smiley I did mean what I wrote. Overrides have caused a
> > lot of subtile problems in several projects we did, and if something
> > goes wrong, it is impossible to remove them except by manually
> > fiddling with the version history in each image that this has been
> > loaded into.
> >
> That's also true for the "not temporary" overwrites. I know it is
> bad but If I need a quick fix for something "possible" useful the
> risk is there. If I do category changes for foreign projects the
> method is gone anyway and I have to load it again from the original
> source. So I meant if using such things than the temporary override
> is less harmful than the permanent.
> But I recognized that saving a new version of a module doesn't mean
> I have to publish it :) This seems much more clever than stomping on
> other peoples code.
>
> Btw. methods can have versions and classes don't. Is there any reason
> for this or just never done?
>
> thanks,
>
> norbert
>
>
>



More information about the Squeak-dev mailing list