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