|
|
>>I wrote:
>>> 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?
>Schrieb Colin Putney:
>> 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.
Bert Freudenberg wrote:
>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.
Thank you for your answers. I like Colin's solution okay, but it
really just allows me to maintain my own packages. I'm not sure I
would want to publish a branch of someone else's package for just two
lines of code. I don't know of a good easy way to handle package
dependencies right now either.
To address Bert's even better answer, and getting away from the
Monticello aspect of this, I am talking about adding items to the
Tweak menus in Croquet, which I would expect to be a popular and
active area for changes. What's a good way to go about menu item
registration?
I have cross-posted this item.
|
Locked
