Hi Christoph,

> So why does MCMethodDefinition >> #unload distinguish between regular extension methods and override extension methods, instead of recovering every method's history? 

Because it could easily fail to do the expected thing. If you clean up code and decide to move something into or between extension categories, you don't want to restore that on unload. That's even tricky with -override stuff if an intermediate state did not get versioned through MC.

Best,
Marcel
Am 17.12.2019 13:00:28 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Marcel, thanks for the pointers! Just fixed that in XmasDecorations :-)

Follow-up question, consider the following (for me, quite likely) scenario: I develop a new convenience method for a system class, for example Collection >> #detect:ifAbsent:. Before committing it to Trunk, I only use it in a separate package as an extension method. Later, it is released via Trunk updates. When I now install my package in an up-to-date image, the category name will not end with '*-override', so unloading the package will delete the method.

So why does MCMethodDefinition >> #unload distinguish between regular extension methods and override extension methods, instead of recovering every method's history? :-)

Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 17. Dezember 2019 11:38:30
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Possible buggy senders of Class >> #category?
 
Hi Christoph,

extensions to classes that are actually overrides -- so that selector was already taken before in that class -- are managed via Monticello through that "-override" suffix.

See:
MCMethodDefinition >> #isOverrideMethod
MCMethodDefinition >> #unload

MCPackage >> #snapshot

My Widgets project does this in Morph:



When unloading Widgets through Monticello, the orignal methods should be restored.



Best,
Marcel

Am 16.12.2019 23:44:39 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
I also heard this the first time now. Many thanks for the tip!

Does this exactly depend on the "override" suffix? So if I overrode dozens of methods, I could not distribute them into special categories?
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von tim Rowledge <tim at rowledge.org>
Gesendet: Montag, 16. Dezember 2019 23:30:11
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Possible buggy senders of Class >> #category?
 


> On 2019-12-16, at 2:20 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> That's exactly what's supposed to happen, if you properly named your category "*xyz-override". By marking a method as override, it belongs to both the original package and the overriding package.

Wait, what? I'm fairly sureI've never seen that mentioned before. Do we have that explained anywhere in plausibly obvious swiki page(s)?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim [http://www.rowledge.org/tim]
If only people came with pull-down menus and online help.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191218/0133f364/attachment.html>