Monticello and overwriting a selector temporary

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Monticello and overwriting a selector temporary

NorbertHartl
Hi,

sometimes I need to change some code of squeak or of a
module I'm using. Monticello is great for doing this.
By just labelling the method category to *mymodule.
But then if the change gets obsoleted (other strategy, module
is fixed) I remove the method category. This leads to the
method being lost. Monticello recognizes that the method
has been removed since the last version and removes it.
Is there a best practice to do this without being this harmful?
This is very annoying if you are developing with other people
which easily can oversee the removal.

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: Monticello and overwriting a selector temporary

Bert Freudenberg
On May 24, 2007, at 10:57 , Norbert Hartl wrote:

> Hi,
>
> sometimes I need to change some code of squeak or of a
> module I'm using. Monticello is great for doing this.
> By just labelling the method category to *mymodule.

Not quite. If you do this, you tell the system that this method moved  
from its original package to your package. *All* the system is  
packaged, even if you do not have a specific package in Monticello.

> But then if the change gets obsoleted (other strategy, module
> is fixed) I remove the method category. This leads to the
> method being lost. Monticello recognizes that the method
> has been removed since the last version and removes it.

Sure. You need to move it back to the original package by having a  
new version of that system package.

> Is there a best practice to do this without being this harmful?
> This is very annoying if you are developing with other people
> which easily can oversee the removal.

Best practice is to not let any package modify other packages.  
Additions (like extension methods in *categories) are fine, but any  
change to other packages is evil. Instead, do the change in the other  
package and distribute a modified version of that package with your  
code, and have other developers merge that version into their images.

So this is best practice.

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 ;)

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Monticello and overwriting a selector temporary

NorbertHartl

>
> 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. :))

thanks,

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: Monticello and overwriting a selector temporary

Bert Freudenberg

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.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Monticello and overwriting a selector temporary

NorbertHartl
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


Reply | Threaded
Open this post in threaded view
|

Re: Monticello and overwriting a selector temporary

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

Cheers
Philippe


2007/5/24, Norbert Hartl <[hidden email]>:

> 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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Monticello and overwriting a selector temporary

stephane ducasse
In reply to this post by Bert Freudenberg
>
> 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.

Yes! Avoid overrides as much as possible but you can get real painful  
bugs.