[Q] Monticello versioning and subclassing

Hi,

I have a Monticello package that is mostly new classes and methods,
but there is a single method in a single existing class that I need to
change to add a couple of lines to in order to tie my code to another
project.  In order to properly subclass the existing class to overload
this one method, I would also need to subclass a number of other
existing classes to change the class references.  This seems like a
lot of extra subclasses for not much gain.

So my questions are:

1.  Does Monticello offer some help with this situation?
2a.  Do I go ahead and just directly modify the existing class method
to add my two lines and mark it as a Monticello class extension, or
2b.  Do I do the right thing and put in all the extra subclasses to
properly overload the whole string of dependent class references?
3.  How do I deal with 2a when the owner of the existing class
modifies that method some other way?

Thanks for any help you can provide.

> 1.  Does Monticello offer some help with this situation?
> 2a.  Do I go ahead and just directly modify the existing class method
> to add my two lines and mark it as a Monticello class extension, or
> 2b.  Do I do the right thing and put in all the extra subclasses to
> properly overload the whole string of dependent class references?
> 3.  How do I deal with 2a when the owner of the existing class
> modifies that method some other way?

Hi David,

If the existing class is part of a Monticello package, the best way  
to deal with it is to just modify the method and save the package.  
You've effectively created your own branch of that package, and as  
new versions are released up stream, you just merge them into your  
branch.

Another option would be to override the existing method. Modify it  
and move it into a category called *mypackage-overrides. This will  
let Monticello know that your package overrides the existing method,  
without "stealing" it from the other package. This mostly works, but  
you can run into problems with overrides because PackageInfo is not a  
real packaging system, and there are corner cases that can cause  
methods to be lost.

Does this help?

Colin

Am 15.06.2006 um 16:06 schrieb Colin Putney:

This is the best way. Even better is that you refactor the package in  
a way to allow your code to hook in without code changes, and submit  
this version to the package maintainer.

> Another option would be to override the existing method. Modify it  
> and move it into a category called *mypackage-overrides. This will  
> let Monticello know that your package overrides the existing  
> method, without "stealing" it from the other package. This mostly  
> works, but you can run into problems with overrides because  
> PackageInfo is not a real packaging system, and there are corner  
> cases that can cause methods to be lost.

it's *mypackage-override, without a trailing "s". But don't use it if  
you don't have to.

- Bert -