The Inbox: System-ct.1131.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: System-ct.1131.mcz

commits-2
Christoph Thiede uploaded a new version of System to project The Inbox:
http://source.squeak.org/inbox/System-ct.1131.mcz

==================== Summary ====================

Name: System-ct.1131
Author: ct
Time: 13 January 2020, 12:21:05.96857 pm
UUID: b10f8320-ffea-024e-9696-4fdc0e642415
Ancestors: System-cmm.1129

Adds support for extension methods to SystemNavigation

=============== Diff against System-cmm.1129 ===============

Item was added:
+ ----- Method: SystemNavigation>>allExtensionsOf: (in category 'query') -----
+ allExtensionsOf: aPackage
+
+ ^ aPackage extensionMethods!

Item was added:
+ ----- Method: SystemNavigation>>browseAllExtensionsOf: (in category 'browse') -----
+ browseAllExtensionsOf: aPackage
+ "self default browseAllExtensionsOf: SystemNavigation package"
+
+ ^ self
+ browseMessageList: [self allExtensionsOf: aPackage]
+ name: ('Extensions of package {1}' translated format: {aPackage name})!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1131.mcz

Jakob Reschke
How about "Extensions from" or "in" instead of "Extensions of" since it is not the package being extended? Native speakers what's your opinion?


<[hidden email]> schrieb am Mo., 13. Jan. 2020, 12:21:
Christoph Thiede uploaded a new version of System to project The Inbox:
http://source.squeak.org/inbox/System-ct.1131.mcz

==================== Summary ====================

Name: System-ct.1131
Author: ct
Time: 13 January 2020, 12:21:05.96857 pm
UUID: b10f8320-ffea-024e-9696-4fdc0e642415
Ancestors: System-cmm.1129

Adds support for extension methods to SystemNavigation

=============== Diff against System-cmm.1129 ===============

Item was added:
+ ----- Method: SystemNavigation>>allExtensionsOf: (in category 'query') -----
+ allExtensionsOf: aPackage
+
+       ^ aPackage extensionMethods!

Item was added:
+ ----- Method: SystemNavigation>>browseAllExtensionsOf: (in category 'browse') -----
+ browseAllExtensionsOf: aPackage
+       "self default browseAllExtensionsOf: SystemNavigation package"
+
+       ^ self
+                       browseMessageList: [self allExtensionsOf: aPackage]
+                       name: ('Extensions of package {1}' translated format: {aPackage name})!




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1131.mcz

Chris Muller-3
But it IS the package being extended.  "Of" is just right.  If you'll pardon the pun, nice extension, Christoph!   :-D

On Mon, Jan 13, 2020 at 1:30 PM Jakob Reschke <[hidden email]> wrote:
How about "Extensions from" or "in" instead of "Extensions of" since it is not the package being extended? Native speakers what's your opinion?


<[hidden email]> schrieb am Mo., 13. Jan. 2020, 12:21:
Christoph Thiede uploaded a new version of System to project The Inbox:
http://source.squeak.org/inbox/System-ct.1131.mcz

==================== Summary ====================

Name: System-ct.1131
Author: ct
Time: 13 January 2020, 12:21:05.96857 pm
UUID: b10f8320-ffea-024e-9696-4fdc0e642415
Ancestors: System-cmm.1129

Adds support for extension methods to SystemNavigation

=============== Diff against System-cmm.1129 ===============

Item was added:
+ ----- Method: SystemNavigation>>allExtensionsOf: (in category 'query') -----
+ allExtensionsOf: aPackage
+
+       ^ aPackage extensionMethods!

Item was added:
+ ----- Method: SystemNavigation>>browseAllExtensionsOf: (in category 'browse') -----
+ browseAllExtensionsOf: aPackage
+       "self default browseAllExtensionsOf: SystemNavigation package"
+
+       ^ self
+                       browseMessageList: [self allExtensionsOf: aPackage]
+                       name: ('Extensions of package {1}' translated format: {aPackage name})!





Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1131.mcz

Christoph Thiede

But I think I need to refine it again ... Actually, I am mixing up system categories and packages here. This seems to be a true n:m relation (n, m >= 0, n + m > 0, to be exact :P), so I would like to introduce two separate selectors, #allExtensionsOfPackage: and #allExtensionsOfSystemCategory:.

However, I did not find any logic in the image to search for extension methods without any package. Is this actually missing, or rather intended ("you cannot extend a system category, but only a package")? I might be completely on the wrong track at the moment ...


(To see the issue, you can simply try to browse all extensions of the UserObjects category.)


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
Gesendet: Dienstag, 14. Januar 2020 07:09:55
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: System-ct.1131.mcz
 
But it IS the package being extended.  "Of" is just right.  If you'll pardon the pun, nice extension, Christoph!   :-D

On Mon, Jan 13, 2020 at 1:30 PM Jakob Reschke <[hidden email]> wrote:
How about "Extensions from" or "in" instead of "Extensions of" since it is not the package being extended? Native speakers what's your opinion?


<[hidden email]> schrieb am Mo., 13. Jan. 2020, 12:21:
Christoph Thiede uploaded a new version of System to project The Inbox:
http://source.squeak.org/inbox/System-ct.1131.mcz

==================== Summary ====================

Name: System-ct.1131
Author: ct
Time: 13 January 2020, 12:21:05.96857 pm
UUID: b10f8320-ffea-024e-9696-4fdc0e642415
Ancestors: System-cmm.1129

Adds support for extension methods to SystemNavigation

=============== Diff against System-cmm.1129 ===============

Item was added:
+ ----- Method: SystemNavigation>>allExtensionsOf: (in category 'query') -----
+ allExtensionsOf: aPackage
+
+       ^ aPackage extensionMethods!

Item was added:
+ ----- Method: SystemNavigation>>browseAllExtensionsOf: (in category 'browse') -----
+ browseAllExtensionsOf: aPackage
+       "self default browseAllExtensionsOf: SystemNavigation package"
+
+       ^ self
+                       browseMessageList: [self allExtensionsOf: aPackage]
+                       name: ('Extensions of package {1}' translated format: {aPackage name})!





Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1131.mcz

Jakob Reschke
Well, the categories define the scope of packages in Squeak, together with the package names. Since system categories do not splice single classes into parts provided by different modules (here: packages), I see no point in the concept of extensions for categories. Packages do define this splicing of classes, and thereby define extension methods, so extension methods do not make sense without packages. Packages get mixed up with categories because the assignment of objects to packages works through categories.

Technically a class would not belong to a package if a) the class were not in any system category or b) there is no package that covers the system category.

But it does not matter in this case:
PackageInfo>>extensionMethods answers the methods that belong to the receiver package, but are defined in classes that do not belong to the same package. That's why this is *not* about the package being extended, but about the package extending other classes. Hence I inquired about the wording of the selectors. The enumerating of methods works by inspecting all subclasses of ProtoObject. So it even includes extension methods of classes that are not in a category or without a package covering the category.

Concerning the cardinality of your package--category association: a package can contain multiple categories (all with the package name as a prefix of the category name, separated from the remainder with a -), but the classes in a category should all belong to a single package. The combined set of methods of these classes need not all belong to the same package because some of them can be extension methods that belong to other packages. You can define overlapping packages, such as Kernel and Kernel-Numbers. Then it is ambiguous to which package the classes in the category Kernel-Numbers belong. But you usually don't want to do that.


Thiede, Christoph <[hidden email]> schrieb am Di., 14. Jan. 2020, 09:02:

But I think I need to refine it again ... Actually, I am mixing up system categories and packages here. This seems to be a true n:m relation (n, m >= 0, n + m > 0, to be exact :P), so I would like to introduce two separate selectors, #allExtensionsOfPackage: and #allExtensionsOfSystemCategory:.

However, I did not find any logic in the image to search for extension methods without any package. Is this actually missing, or rather intended ("you cannot extend a system category, but only a package")? I might be completely on the wrong track at the moment ...


(To see the issue, you can simply try to browse all extensions of the UserObjects category.)


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
Gesendet: Dienstag, 14. Januar 2020 07:09:55
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: System-ct.1131.mcz
 
But it IS the package being extended.  "Of" is just right.  If you'll pardon the pun, nice extension, Christoph!   :-D

On Mon, Jan 13, 2020 at 1:30 PM Jakob Reschke <[hidden email]> wrote:
How about "Extensions from" or "in" instead of "Extensions of" since it is not the package being extended? Native speakers what's your opinion?


<[hidden email]> schrieb am Mo., 13. Jan. 2020, 12:21:
Christoph Thiede uploaded a new version of System to project The Inbox:
http://source.squeak.org/inbox/System-ct.1131.mcz

==================== Summary ====================

Name: System-ct.1131
Author: ct
Time: 13 January 2020, 12:21:05.96857 pm
UUID: b10f8320-ffea-024e-9696-4fdc0e642415
Ancestors: System-cmm.1129

Adds support for extension methods to SystemNavigation

=============== Diff against System-cmm.1129 ===============

Item was added:
+ ----- Method: SystemNavigation>>allExtensionsOf: (in category 'query') -----
+ allExtensionsOf: aPackage
+
+       ^ aPackage extensionMethods!

Item was added:
+ ----- Method: SystemNavigation>>browseAllExtensionsOf: (in category 'browse') -----
+ browseAllExtensionsOf: aPackage
+       "self default browseAllExtensionsOf: SystemNavigation package"
+
+       ^ self
+                       browseMessageList: [self allExtensionsOf: aPackage]
+                       name: ('Extensions of package {1}' translated format: {aPackage name})!






Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1131.mcz

Christoph Thiede

Hi Jakob, thanks for the comprehensive explanation! :-)


You can define overlapping packages, such as Kernel and Kernel-Numbers.


You mean Kernel-Objects? What is the reason we have defined these overlapping packages?

#packageOfSystemCategory: works nondeterministic here.


Still, what I would like to make possible with this feature is to browse all extensions of Tools-Inspector, for example -- which is not an extra package, but only a system category. Personally, I would find this quite useful in certain situations.

Should we maybe just create a temporary package for this use case, on the fly when #allExtensionsOfSystemCategory: is called? Or would this be _too_ hacky? ^^


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 18. Januar 2020 22:21:42
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: System-ct.1131.mcz
 
Well, the categories define the scope of packages in Squeak, together with the package names. Since system categories do not splice single classes into parts provided by different modules (here: packages), I see no point in the concept of extensions for categories. Packages do define this splicing of classes, and thereby define extension methods, so extension methods do not make sense without packages. Packages get mixed up with categories because the assignment of objects to packages works through categories.

Technically a class would not belong to a package if a) the class were not in any system category or b) there is no package that covers the system category.

But it does not matter in this case:
PackageInfo>>extensionMethods answers the methods that belong to the receiver package, but are defined in classes that do not belong to the same package. That's why this is *not* about the package being extended, but about the package extending other classes. Hence I inquired about the wording of the selectors. The enumerating of methods works by inspecting all subclasses of ProtoObject. So it even includes extension methods of classes that are not in a category or without a package covering the category.

Concerning the cardinality of your package--category association: a package can contain multiple categories (all with the package name as a prefix of the category name, separated from the remainder with a -), but the classes in a category should all belong to a single package. The combined set of methods of these classes need not all belong to the same package because some of them can be extension methods that belong to other packages. You can define overlapping packages, such as Kernel and Kernel-Numbers. Then it is ambiguous to which package the classes in the category Kernel-Numbers belong. But you usually don't want to do that.


Thiede, Christoph <[hidden email]> schrieb am Di., 14. Jan. 2020, 09:02:

But I think I need to refine it again ... Actually, I am mixing up system categories and packages here. This seems to be a true n:m relation (n, m >= 0, n + m > 0, to be exact :P), so I would like to introduce two separate selectors, #allExtensionsOfPackage: and #allExtensionsOfSystemCategory:.

However, I did not find any logic in the image to search for extension methods without any package. Is this actually missing, or rather intended ("you cannot extend a system category, but only a package")? I might be completely on the wrong track at the moment ...


(To see the issue, you can simply try to browse all extensions of the UserObjects category.)


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
Gesendet: Dienstag, 14. Januar 2020 07:09:55
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: System-ct.1131.mcz
 
But it IS the package being extended.  "Of" is just right.  If you'll pardon the pun, nice extension, Christoph!   :-D

On Mon, Jan 13, 2020 at 1:30 PM Jakob Reschke <[hidden email]> wrote:
How about "Extensions from" or "in" instead of "Extensions of" since it is not the package being extended? Native speakers what's your opinion?


<[hidden email]> schrieb am Mo., 13. Jan. 2020, 12:21:
Christoph Thiede uploaded a new version of System to project The Inbox:
http://source.squeak.org/inbox/System-ct.1131.mcz

==================== Summary ====================

Name: System-ct.1131
Author: ct
Time: 13 January 2020, 12:21:05.96857 pm
UUID: b10f8320-ffea-024e-9696-4fdc0e642415
Ancestors: System-cmm.1129

Adds support for extension methods to SystemNavigation

=============== Diff against System-cmm.1129 ===============

Item was added:
+ ----- Method: SystemNavigation>>allExtensionsOf: (in category 'query') -----
+ allExtensionsOf: aPackage
+
+       ^ aPackage extensionMethods!

Item was added:
+ ----- Method: SystemNavigation>>browseAllExtensionsOf: (in category 'browse') -----
+ browseAllExtensionsOf: aPackage
+       "self default browseAllExtensionsOf: SystemNavigation package"
+
+       ^ self
+                       browseMessageList: [self allExtensionsOf: aPackage]
+                       name: ('Extensions of package {1}' translated format: {aPackage name})!






Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1131.mcz

Jakob Reschke
In addition to what I wrote, maybe take a look at PackagePaneBrowser.

Am So., 19. Jan. 2020 um 13:10 Uhr schrieb Thiede, Christoph <[hidden email]>:

You mean Kernel-Objects?

There is no such thing in the Trunk repository. 

What is the reason we have defined these overlapping packages?

I don't think there is a reason except for mistakes, or splitting up or merging packages later. 

Still, what I would like to make possible with this feature is to browse all extensions of Tools-Inspector, for example -- which is not an extra package, but only a system category. Personally, I would find this quite useful in certain situations.

What exactly do you want to see? List all extension methods on classes in the selected category? Or find all extension methods outside of the selected category? The latter does not make sense without a package. The former does not match the code you posted, as far as I understand it. 

Should we maybe just create a temporary package for this use case, on the fly when #allExtensionsOfSystemCategory: is called? Or would this be _too_ hacky? ^^

In both of the cases above, I think it does not make sense to create a temporary package. The package is Tools, so it does not make sense to search for extensions provided by Tools-Inspector, does it? To find extension methods on classes in Tools-Inspector, you don't need a package.

Kind regards,
Jakob


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1131.mcz

Christoph Thiede

Hi Jakob,


> > You mean Kernel-Objects?

> There is no such thing in the Trunk repository. 

Oh, sorry, I had created it by accident in past (before I realized that PackageInfo >> #named: does not only perform a lookup, but also constructs a package if necessary).


In addition to what I wrote, maybe take a look at PackagePaneBrowser.


Yes, I already prepared an extension of its package menu, too, it's still waiting in my image :)


> > Still, what I would like to make possible with this feature is to browse all extensions of Tools-Inspector, for example -- which is not an extra package, but only a system category. Personally, I would find this quite useful in certain situations.

> What exactly do you want to see? List all extension methods on classes in the selected category? Or find all extension methods outside of the selected category?

The latter.
For example, the Tools package defines a lot of extension methods over the whole system.
There are many '*Tools-Inspector' extension categories, many '*Tools-Debugger' extension categories and so on ...

[self systemNavigation browseAllExtensionsOf: Inspector package] will bring up all extensions to the Tools package, which is fine.
But it would be great if [self systemNavigation browseAllExtensionsOf: Inspector category] brought up all extension to the Tools package that are specific to the Inspector only, instead.

it does not make sense to search for extensions provided by Tools-Inspector, does it?

I think it could make sense indeed, see above. As you stated, we don't need overlapping packages, but in my scenario, it would be helpful to filter extensions by a higher granularity than packages.

What you can do at the moment is manual filtering:


Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Sonntag, 19. Januar 2020 13:31:40
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: System-ct.1131.mcz
 
In addition to what I wrote, maybe take a look at PackagePaneBrowser.

Am So., 19. Jan. 2020 um 13:10 Uhr schrieb Thiede, Christoph <[hidden email]>:

You mean Kernel-Objects?

There is no such thing in the Trunk repository. 

What is the reason we have defined these overlapping packages?

I don't think there is a reason except for mistakes, or splitting up or merging packages later. 

Still, what I would like to make possible with this feature is to browse all extensions of Tools-Inspector, for example -- which is not an extra package, but only a system category. Personally, I would find this quite useful in certain situations.

What exactly do you want to see? List all extension methods on classes in the selected category? Or find all extension methods outside of the selected category? The latter does not make sense without a package. The former does not match the code you posted, as far as I understand it. 

Should we maybe just create a temporary package for this use case, on the fly when #allExtensionsOfSystemCategory: is called? Or would this be _too_ hacky? ^^

In both of the cases above, I think it does not make sense to create a temporary package. The package is Tools, so it does not make sense to search for extensions provided by Tools-Inspector, does it? To find extension methods on classes in Tools-Inspector, you don't need a package.

Kind regards,
Jakob



pastedImage.png (25K) Download Attachment
pastedImage.png (75K) Download Attachment
Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1131.mcz

Jakob Reschke
Am So., 19. Jan. 2020 um 13:59 Uhr schrieb Thiede, Christoph <[hidden email]>:

What you can do at the moment is manual filtering:



...or just type "debugger" in the list to use the built-in filtering of the list view. :-)


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1131.mcz

Christoph Thiede

... yes, but that feels kind of workaround :-)


Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Sonntag, 19. Januar 2020 14:45:39
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: System-ct.1131.mcz
 
Am So., 19. Jan. 2020 um 13:59 Uhr schrieb Thiede, Christoph <[hidden email]>:

What you can do at the moment is manual filtering:



...or just type "debugger" in the list to use the built-in filtering of the list view. :-)


Carpe Squeak!