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
|