Why are package tags not proper sub-packages?
Does anyone remember why we decided to consider package tags (as in: Kernel-BasicObjects) not fully fledged sub-packages? The implication here is that extension methods canât live on the tag (they live on the parent package - in the above case Kernel - and not Kernel-BasicObjects), and equally the code critic works on the package level and not on an individual tag. Equally, refactoring can work at the package level ⦠the list goes on. Having decided that it seemed to make it more understandable that Exercism exercises would simply be tags of the package exercism (its tidy to have the exercises neatly organised under a common parent with some generic menu options), I am finding that the above are starting to bite me. Extensions, Code critic (and sometimes refactoring) are awkward or more difficult to explain, and I was left wondering what the rational was to not make the tags fully fledged sub projects? Iâm now wondering if I should bite the bullet and migrate every exercise tag to being a fully formed project (although in most cases it seems overkill for a class and a test). But Iâm interested in the history of this one as maybe it can guide me? Tim
On Wed, 17 Apr 2019 at 05:53, Tim Mackinnon <tim@testit.works> wrote:
Does anyone remember why we decided to consider package tags (as in: Kernel-BasicObjects) not fully fledged sub-packages?
The implication here is that extension methods canât live on the tag (they live on the parent package - in the above case Kernel - and not Kernel-BasicObjects), and equally the code critic works on the package level and not on an individual tag. Equally, refactoring can work at the package level ⦠the list goes on.
Having decided that it seemed to make it more understandable that Exercism exercises would simply be tags of the package exercism (its tidy to have the exercises neatly organised under a common parent with some generic menu options), I am finding that the above are starting to bite me. Extensions, Code critic (and sometimes refactoring) are awkward or more difficult to explain, and I was left wondering what the rational was to not make the tags fully fledged sub projects?
I hope someone involved in the design will answer in more detail, but overall what I remember from observed discussions is that in moving from string-based Categorizations to RPackage objects there was a tough decision made to keep compatibility with strings for sake of interchange with other dialects - and *perhaps* that impacted how package tags were designed, and our Exercism use case is now just exposing some gap there.
Iâm now wondering if I should bite the bullet and migrate every exercise tag to being a fully formed project (although in most cases it seems overkill for a class and a test).
I have also the feeling that it may be overkill, but I've come to the same conclusion that the exercises are probably better as separate packages. cheers -ben
Ben Coman wrote
The implication here is that extension methods canât live on the tag (they live on the parent package
Won't that cause existing code not designed with that restriction in mind to be lost on save? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Thatâs the struggle I face - I might be able to coerce Calypso to show extension methods in the tag, but there seems no way to understand what tag it/they are associated with - which also got me to the catch you mention, when saving an exercise I canât know what extensions to save with it... Iâd have to Save them all and this will end up as a big mess when loading different exercises later. I wish Iâd known this job hasnât been finished and Iâm curious why itâs not on the roadmap anymore if itâs a stepping stone (unless it means Cargo - but that seems to have been lowered in priority?) Tim Sent from my iPhone
On 19 Apr 2019, at 03:24, Sean P. DeNigris <sean@clipperadams.com> wrote:
Ben Coman wrote
The implication here is that extension methods canât live on the tag (they live on the parent package
Won't that cause existing code not designed with that restriction in mind to be lost on save?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Tim Mackinnon wrote
Thatâs the struggle I face
If that's the case, this sounds like a huge problem. I'm surprised no one has reported it already. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Well I guess most usages are âload 3rd party baselineâ and you donât really care who owns the extension methods (all the sub-tags are normally part of the parent project anyway). If you do add any extensions to that project, you probably also donât notice they donât show up in any tags of the classes you extend (only in the containing project). Itâs subtle but probably doesnât affect execution, just readability. Tim Sent from my iPhone
On 19 Apr 2019, at 18:10, Sean P. DeNigris <sean@clipperadams.com> wrote:
If that's the case, this sounds like a huge problem. I'm surprised no one has reported it already.
I chatted with guys about this - and it turns out that I was thinking of packages as if they were projects, however in reality we are waiting for a proper âprojectâ model (this is what Cargo - whoâs new name Iâve forgotten - is all about). So I should promote my use of tags up to proper packages and for now âprefixâ my packages with a project name. This might explain why when you create a unit test , it creates an automatic top level package (and not a tag), which has often confused me in the past. Iâm still a bit unsure what tags would then be used for in a world with projects. But it seems that the guidance is to think projects / packages (not baseline/package/tags) Tim Sent from my iPhone
On 20 Apr 2019, at 00:15, Tim Mackinnon <tim@testit.works> wrote:
Well I guess most usages are âload 3rd party baselineâ and you donât really care who owns the extension methods (all the sub-tags are normally part of the parent project anyway).
If you do add any extensions to that project, you probably also donât notice they donât show up in any tags of the classes you extend (only in the containing project). Itâs subtle but probably doesnât affect execution, just readability.
Tim
Sent from my iPhone
On 19 Apr 2019, at 18:10, Sean P. DeNigris <sean@clipperadams.com> wrote:
If that's the case, this sounds like a huge problem. I'm surprised no one has reported it already.
participants (3)
-
Ben Coman -
Sean P. DeNigris -
Tim Mackinnon