On 16 sept. 05, at 14:57, Martin Wirblat wrote:


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

I agree but overrides can be nasty also with load order.

By the way, if you have fixes that you want to see moved into the  
next release. Send them


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

Yes this would be nice.


>
> Regards,
> Martin
>
>
>