Smalltalk › Squeak › Squeak - Dev

Possible buggy senders of Class >> #category?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Christoph Thiede

Possible buggy senders of Class >> #category?

Hi all,

is it a valid state for a class's category to be nil? I recently got an error in Class >> #isDeprecated because [self category] was nil. Unfortunately, I cannot reproduce it, but I guess it happened in the context of uniclasses.

Should we make the following change?

Best,

Christoph

Carpe Squeak!

marcel.taeumel

Re: Possible buggy senders of Class >> #category?

Hi Christoph,

no, the return value of "someClass category" should never be 'nil'.

> but I guess it happened in the context of uniclasses.

Uniclasses should be stored in #UserObjects.

> Should we make the following change?

Please don't. Instead, make sure that after

"ReleaseBuilder prepareSourceCode; clearCaches"

all those strange classes are either gone or fixed.

Best,

Marcel

Am 13.12.2019 19:13:12 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

is it a valid state for a class's category to be nil? I recently got an error in Class >> #isDeprecated because [self category] was nil. Unfortunately, I cannot reproduce it, but I guess it happened in the context of uniclasses.

Should we make the following change?

Best,

Christoph

Christoph Thiede

Re: Possible buggy senders of Class >> #category?

Hi Marcel,

weird, I cannot reproduce this.

"Class allSubInstances select: [:c | c category isNil]"

gives me a handful Player subclasses.

> "ReleaseBuilder prepareSourceCode; clearCaches"

I can't execute this, I have too many packages installed that override critical system methods ...

(It would be great if we had some "recover stashed code" logic someday: If a package is uninstalled, don't remove all extension methods, but check for previous versions that are not in the package which is currently to be uninstalled and, if found, revert to the latest original version.)

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Freitag, 13. Dezember 2019 19:26:00
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Possible buggy senders of Class >> #category?

Hi Christoph,

no, the return value of "someClass category" should never be 'nil'.

> but I guess it happened in the context of uniclasses.

Uniclasses should be stored in #UserObjects.

> Should we make the following change?

Please don't. Instead, make sure that after

"ReleaseBuilder prepareSourceCode; clearCaches"

all those strange classes are either gone or fixed.

Best,

Marcel

Am 13.12.2019 19:13:12 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

is it a valid state for a class's category to be nil? I recently got an error in Class >> #isDeprecated because [self category] was nil. Unfortunately, I cannot reproduce it, but I guess it happened in the context of uniclasses.

Should we make the following change?

Best,

Christoph

Carpe Squeak!

Bert Freudenberg

Re: Possible buggy senders of Class >> #category?

On Fri, Dec 13, 2019 at 11:54 AM Thiede, Christoph <[hidden email]> wrote:

(It would be great if we had some "recover stashed code" logic someday: If a package is uninstalled, don't remove all extension methods, but check for previous versions that are not in the package which is currently to be uninstalled and, if found, revert to the latest original version.)

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.

- Bert -

image.png (9K) Download Attachment

timrowledge

Re: Possible buggy senders of Class >> #category?

> On 2019-12-16, at 2:20 PM, Bert Freudenberg <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
If only people came with pull-down menus and online help.

Christoph Thiede

Re: Possible buggy senders of Class >> #category?

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 <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
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?

Carpe Squeak!

marcel.taeumel

Re: 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 <[hidden email]>:

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 <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
If only people came with pull-down menus and online help.

Christoph Thiede

Re: Possible buggy senders of Class >> #category?

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
If only people came with pull-down menus and online help.

Carpe Squeak!

Bert Freudenberg

Re: Possible buggy senders of Class >> #category?

In reply to this post by timrowledge

On Mon, Dec 16, 2019 at 2:30 PM tim Rowledge <[hidden email]> wrote:

> On 2019-12-16, at 2:20 PM, Bert Freudenberg <[hidden email]> 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.

I'm pretty sure that has been your reaction every time we mention it ;)

Do we have that explained anywhere in plausibly obvious swiki page(s)?

Not that I know of. :(

- Bert -

Bert Freudenberg

Overriding method categories (was: Possible buggy senders of Class >> #category?)

In reply to this post by Christoph Thiede

On Mon, Dec 16, 2019 at 2:44 PM Thiede, Christoph <[hidden email]> wrote:

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?

It's independent - if the category starts with '*package-name' it is considered part of the package, and if it ends with '-override' it is an override.

So *pkg-name-foo-bar-override is fine.

That being said, this is only considered a band-aid to patch packages you do not want to change. That's why we don't have any examples of this in the base system, and proper external packages also should not use it.

It's more intended for "I want to locally modify this method, but that shouldn't make the package dirty" or "My package has to do this one weird hack and there is no way to refactor the original package" scenarios.

- Bert -

timrowledge

Re: Possible buggy senders of Class >> #category?

In reply to this post by Bert Freudenberg

> On 2019-12-17, at 11:45 AM, Bert Freudenberg <[hidden email]> wrote:
>
> I'm pretty sure that has been your reaction every time we mention it ;)

Well that's not impossible but searching reveals no emails on the subject in my archive. I actually thought of MC as simply not dealing in overrides at all. We should definitely add a decent explanation to the swiki page(s).

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Cave ne ante ullas catapultas ambules = If I were you, I wouldn't walk in front of any catapults.

Tobias Pape

Re: Possible buggy senders of Class >> #category?

> On 17.12.2019, at 21:57, tim Rowledge <[hidden email]> wrote:
>
>
>
>> On 2019-12-17, at 11:45 AM, Bert Freudenberg <[hidden email]> wrote:
>>
>> I'm pretty sure that has been your reaction every time we mention it ;)
>
> Well that's not impossible but searching reveals no emails on the subject in my archive. I actually thought of MC as simply not dealing in overrides at all. We should definitely add a decent explanation to the swiki page(s).

We should definitely add decent URLs to swiki as well.

SCNR :)

-y

Tobias Pape

Re: Possible buggy senders of Class >> #category?

> On 17.12.2019, at 23:04, Tobias Pape <[hidden email]> wrote:
>
>
>> On 17.12.2019, at 21:57, tim Rowledge <[hidden email]> wrote:
>>
>>
>>
>>> On 2019-12-17, at 11:45 AM, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> I'm pretty sure that has been your reaction every time we mention it ;)
>>
>> Well that's not impossible but searching reveals no emails on the subject in my archive. I actually thought of MC as simply not dealing in overrides at all. We should definitely add a decent explanation to the swiki page(s).
>
> We should definitely add decent URLs to swiki as well.
>
> SCNR :)
>
> -y

That's what you get for not paying attention and not resisting. Sorry.

Best regards
-Tobias

marcel.taeumel

Re: Possible buggy senders of Class >> #category?

In reply to this post by Christoph Thiede

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
If only people came with pull-down menus and online help.