Open LinqLover opened 2 years ago
Because I did not want to override the existing methods and functionality if it is already present.
Now that Squeak 6.0 is here I could reconsider.
But now you could put the extension methods into the right compatibility package, couldn't you? Wouldn't this allow for clearer tracking of the origin of these overrides? Same for https://github.com/hpi-swa/Squot/commit/21e866477a037df3577c5737bc4fae2e7f9a2908#diff-e8aa5f417f3a14ad795b10c7c80746624d2c2a785cd04e3f5d5feab8b698cfe.
Since this is in FileSystem-Git, not in Squot, I would have to create compatibility packages there in the first place. But wait, maybe the SquotCompatibility-SqueakCommon package is actually mislabelled now, since I certainly did not rely on Pharo methods in the "new" code (as compared to the "old" code in FileSystem-Git and FileSystem)!
Indeed, only FileSystem-Git code uses things from SquotCompatibility-SqueakCommon. With the old name Pharo-Compatbility it did not matter which code used it. :-) So I could rename that package.
But for the stub methods for read-only objects I would anyway need another compat package because the methods are available in Squeak 6.0, and the SquotCompatibility-Squeak50 has indeed methods used by Squot, not by FileSystem-Git.
While installing Squot in a fresh Squeak 5.3 image, I hit an unexpected "enter author initials" question:
In other scenarios, this might break CIs. Why can't we use
-override
extension methods here?