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
