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

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

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 <[hidden email]> 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