Publishing on Monticello

Martin Wirblat sql.mawi at t-link.de
Fri Sep 16 12:57:55 UTC 2005


Andreas Raab wrote:
> Michaël Piel wrote:
> 
>> You can also use the "override" method to do that. put your
>> changed methods in a category named "*<YourPackageName>-
>> <originalCategoryName>-override". Thus, These changed methods
>> will be put as *Extensions in your package but the original
>> package will not appear as modified in the monticello browser
>> (wich is interesting if you made this package a dependency of
>> yours). And finally, if you unload your package the orignal methods
>> you changed will be restored.
> 
> Generally speaking this is an evil thing to do. In my experience (which 
> is plenty by now) having overrides typically points to either a bug you 
> have to fix or an inflexibility (for some extension of yours) in the 
> original design. Both are better solved by keeping a modified version of 
> the original package rather than using overrides. Personally, by now I 
> really think it would be better if MC wouldn't support overrides at all.
> 
> Cheers,
>   - Andreas
> 
> 

Keeping a modified version of the original package. What does that mean?

For publishing e.g. on SM you then would have to publish the modified 
version of the original package, too. It is probably big and has nothing 
to do with your application. As soon as the original changes, the 
modified version had to be synchronized. All that because of one changed 
method? For publishing packages it should be of course tried by all 
means to not override anything, but if this is not possible some more 
elegant method seems to be needed.

For private use this may not look much different. For instance, I am 
regularly "fixing some inflexibilities of the official image" before I 
use it, by overriding some things of the UI and perhaps other things. Is 
that better done by creating some big modified versions of original 
packages just because of a few changed methods? When the next image - or 
worse the next interim update - comes out, I would have to sort out my 
few changes from the possibly many official changes applied to the 
package in the meantime.

As long as you are developing a master image, it is the right way to 
create modified versions of original packages. They immediately become 
the new originals;) This kind of work is wonderfully supported by 
Monticello with its many merging facilities. Nonetheless, if you want to 
develop a second master *partly* synchronized with another master line, 
there will be much work waiting for you, accumulating over time...

For all other purposes that want to derive from a master but want to 
develop with the master (and that is the standard case), some sort of 
"delta functionality" is needed. This delta should be as smoothly as 
possible addable to the next version of the master, because this work 
has to be done manifold (by the millions of the future, that are going 
to use Squeak:)

Monticello seems to me not being so well suited for this task. Either it 
should be accompanied by a module system like the one of Henrik, or 
perhaps it is sufficient that it will be extended with this delta 
functionality.

In case of overridden methods I would like to see the module or source 
code management system being able to inform me if the original method 
has been changed (or removed) since I replaced it. Just to check if it 
has a newer or older date than my replacement is not enough here, 
because I could have written my replacement before or after the birthday 
of the new official method.

Regards,
Martin



More information about the Squeak-dev mailing list