Why are package tags not proper sub-packages?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Why are package tags not proper sub-packages?

Tim Mackinnon
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
Reply | Threaded
Open this post in threaded view
|

Re: Why are package tags not proper sub-packages?

Ben Coman


On Wed, 17 Apr 2019 at 05:53, Tim Mackinnon <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Why are package tags not proper sub-packages?

Sean P. DeNigris
Administrator
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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Why are package tags not proper sub-packages?

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


Reply | Threaded
Open this post in threaded view
|

Re: Why are package tags not proper sub-packages?

Sean P. DeNigris
Administrator
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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Why are package tags not proper sub-packages?

Tim Mackinnon
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.


Reply | Threaded
Open this post in threaded view
|

Re: Why are package tags not proper sub-packages?

Tim Mackinnon
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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> If that's the case, this sounds like a huge problem. I'm surprised no one
>> has reported it already.
>
>