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 <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob at resfarm.de>
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 <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> 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 <squeak-dev-bounces at lists.squeakfoundation.org<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von Chris Muller <asqueaker at gmail.com<mailto:asqueaker at gmail.com>>
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 <forums.jakob at resfarm.de<mailto:forums.jakob at resfarm.de>> 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?


<commits at source.squeak.org<mailto:commits at source.squeak.org>> 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})!




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200119/1ff8c01f/attachment.html>