Smalltalk › Pharo › Pharo Smalltalk Users

Pharo Video Tutorial: Package Tags

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

kilon.alios

Pharo Video Tutorial: Package Tags

In this Episode of "Pharo Video Tutorial" we take a look at "Package tags" and how we can use them to organise our classes and packages to make our lives easier

https://www.youtube.com/watch?v=Q2Vwg_0RMVU&list=PLqbtQ7OkSta0ULYAd7Qdxof851ybh-_m_&index=25

Ben Coman

Re: Pharo Video Tutorial: Package Tags

On Wed, Jun 3, 2015 at 3:34 PM, Dimitris Chloupis <[hidden email]> wrote:
> In this Episode of "Pharo Video Tutorial" we take a look at "Package tags"
> and how we can use them to organise our classes and packages to make our
> lives easier
>
> https://www.youtube.com/watch?v=Q2Vwg_0RMVU&list=PLqbtQ7OkSta0ULYAd7Qdxof851ybh-_m_&index=25

Looks good. Thanks kilon.

but maybe we should to change the dialog title from "Create new
category" to "Create new package tag" ??

cheers -ben

Sergio Fedi

Re: Pharo Video Tutorial: Package Tags

Since Tags have a different behaviour than Packages, I think we should.

(specially when adding comments, which Packages support and Tags don't)

kilon.alios

Re: Pharo Video Tutorial: Package Tags

In reply to this post by Ben Coman

thanks

I dont like the name "tag" its too generic. I would prefer something like "Create new sub-package"

On Wed, Jun 3, 2015 at 12:43 PM Ben Coman <[hidden email]> wrote:

On Wed, Jun 3, 2015 at 3:34 PM, Dimitris Chloupis <[hidden email]> wrote:
> In this Episode of "Pharo Video Tutorial" we take a look at "Package tags"
> and how we can use them to organise our classes and packages to make our
> lives easier
>
> https://www.youtube.com/watch?v=Q2Vwg_0RMVU&list=PLqbtQ7OkSta0ULYAd7Qdxof851ybh-_m_&index=25

Looks good. Thanks kilon.

but maybe we should to change the dialog title from "Create new
category" to "Create new package tag" ??

cheers -ben

Sergio Fedi

Re: Pharo Video Tutorial: Package Tags

I have several issues with this part of the system.

If something is a tag, then you should be able to apply multiple tags to something.

If not, then they are, as you say, subpackages.

Sean P. DeNigris

Re: Pharo Video Tutorial: Package Tags

Administrator

Sergio Fedi wrote

If something is a tag, then you should be able to apply multiple tags to
something.

If not, then they are, as you say, subpackages.

Agreed. Actually, tags are more interesting as they would be much more valuable to users, who want a logical domain view of the system. Currently, the package tree we provide is more a Package Browser than a System Browser.

And... tags are orthogonal to packages. The way we use them, sub-packages seems more correct.

Cheers,
Sean

stepharo

Re: Pharo Video Tutorial: Package Tags

In reply to this post by Sergio Fedi

Guys

I would not use sub-packages. Think about newbies please.
We have packages and tags and ideally I would remove tags but we will
not because else people will cry.

Stef

Le 3/6/15 12:30, Sergio Fedi a écrit :
> Since Tags have a different behaviour than Packages, I think we should.
> (specially when adding comments, which Packages support and Tags don't)
>
>

Thierry Goubier

Re: Pharo Video Tutorial: Package Tags

Le 04/06/2015 21:30, stepharo a écrit :
> Guys
>
> I would not use sub-packages. Think about newbies please.
> We have packages and tags and ideally I would remove tags but we will
> not because else people will cry.

I would cry because I remember Pharo going through the RPackage without
tags idea and how it was killed and replaced by RPackage + Tags.

(It's there somewhere in AltBrowser github history, along with the Spec
version of AltBrowser... looked and felt exactly like today's
packageName + tags, by the way )

Thierry

>
> Stef
>
> Le 3/6/15 12:30, Sergio Fedi a écrit :
>> Since Tags have a different behaviour than Packages, I think we should.
>> (specially when adding comments, which Packages support and Tags don't)
>>
>>
>
>
>
>

Peter Uhnak

Re: Pharo Video Tutorial: Package Tags

On Wed, Jun 3, 2015 at 1:19 PM, Sergio Fedi <[hidden email]> wrote:

If something is a tag, then you should be able to apply multiple tags to something.

Well you sort-of can do that. Consider how many packages have tag "Tests" in it. They don't need to be globally unique and it makes sense to use the very same tag in different packages... so at least for me tag is perfectly fitting name.

On Thu, Jun 4, 2015 at 9:35 PM, Thierry Goubier <[hidden email]> wrote:

Le 04/06/2015 21:30, stepharo a écrit :

Guys

I would not use sub-packages. Think about newbies please.
We have packages and tags and ideally I would remove tags but we will
not because else people will cry.

Why would you want to remove them? What is the damage they are incurring? I find them very useful for organization and judging by packages of other people I am not alone.

Peter

kilon.alios

Re: Pharo Video Tutorial: Package Tags

In reply to this post by stepharo

how that would improve Pharo ?

On Thu, Jun 4, 2015 at 10:30 PM stepharo <[hidden email]> wrote:

Guys

I would not use sub-packages. Think about newbies please.
We have packages and tags and ideally I would remove tags but we will
not because else people will cry.

Stef

Le 3/6/15 12:30, Sergio Fedi a écrit :
> Since Tags have a different behaviour than Packages, I think we should.
> (specially when adding comments, which Packages support and Tags don't)
>
>

Sergio Fedi

Re: Pharo Video Tutorial: Package Tags

In reply to this post by Peter Uhnak

>> If something is a tag, then you should be able to apply multiple tags to something.
> Well you sort-of can do that. Consider how many packages have tag "Tests" in it. They don't need to be globally unique and it makes sense to use the very same tag in different packages... so at least for me tag is perfectly fitting name.

If you could use Tags as tags, then you could have this

Car -> Model

CarTest -> Model, Tests

CarFactory -> Factories

CarFactoryTest -> Factories, Tests

Thus, you could browse different groups of classes anyway you want:

Has tag: Model

Classes: Car, CarTest

Has tag: Model, no-Tests

Classes: Car

Has tag: Tests

Classes: CarTest, CarFactoryTest

Has tag: Factores, Tests

Classes: CarFactoryTest

Imagine then that you could also make tags to show which classes implement a certain Pattern, so now you could browse different implementations of a specific Pattern all accoress your image.

Tagging in any domain is an extremely useful feature.

So is adding notes/comments, but that's another topic.

Ben Coman

Re: Pharo Video Tutorial: Package Tags

On Sat, Jun 6, 2015 at 7:30 AM, Sergio Fedi <[hidden email]> wrote:

>>> If something is a tag, then you should be able to apply multiple tags to
>>> something.
>> Well you sort-of can do that. Consider how many packages have tag "Tests"
>> in it. They don't need to be globally unique and it makes sense to use the
>> very same tag in different packages... so at least for me tag is perfectly
>> fitting name.
>
> If you could use Tags as tags, then you could have this
>
> Car -> Model
> CarTest -> Model, Tests
> CarFactory -> Factories
> CarFactoryTest -> Factories, Tests
>
> Thus, you could browse different groups of classes anyway you want:
>
> Has tag: Model
> Classes: Car, CarTest
>
> Has tag: Model, no-Tests
> Classes: Car
>
> Has tag: Tests
> Classes: CarTest, CarFactoryTest
>
> Has tag: Factores, Tests
> Classes: CarFactoryTest
>
> Imagine then that you could also make tags to show which classes implement a
> certain Pattern, so now you could browse different implementations of a
> specific Pattern all accoress your image.
>
> Tagging in any domain is an extremely useful feature.
> So is adding notes/comments, but that's another topic.

I am not clear on the internals dealing with "tag" , but in your
example I guess the tags needs to be associated with classes, but our
current "tag"s are associated with a packages?

If tags are used how you describe, I wonder if our package
"categories" then become tag filter expressions. Perhaps
GT-Tests-Spotter makes a good example, tagging classes as: Exceptions;
Scripting; and Mocks. You might simultaneously have filter categories:
* Exceptions
* Scripting
* Mocks
* Exceptions,Mocks
* Scripting,Mocks

cheers -ben

Sergio Fedi

Re: Pharo Video Tutorial: Package Tags

The examples you listed are awesome.

When I first saw Tags on the system browser I thought they behaved that way.

Peter Uhnak

Re: Pharo Video Tutorial: Package Tags

I am not clear on the internals dealing with "tag" , but in your
example I guess the tags needs to be associated with classes, but our
current "tag"s are associated with a packages?

Yeah at least to me it feels that it is associated more with packages.

GT-Tests-Spotter makes a good example, tagging classes as: Exceptions;
Scripting; and Mocks. You might simultaneously have filter categories:
* Exceptions
* Scripting
* Mocks
* Exceptions,Mocks
* Scripting,Mocks

To me this seems like unreasonable amount of extra effort and shit ton of cognitive load with no obvious benefit.

Sure, tags are powerful in theory; but to make them work you need to apply them consistently throughout the whole system to get the benefit.

_For me_ this seems like unproportinal amount of effort with little gain.

E.g. Gmail allows to tag emails, yet I treat it very hierarchically; that way I there is always only one way --- the most meaningful of them to get to it; otherwise I would have to think about all the various contexts in which it could be accessed.

So getting back to Pharo's tags, I like the fact that there are some common namings, such as many packages will have tags like "Examples", or "Tests", however I still fail to see why would you want to put one class into multiple tags and what the benefit would be.

Peter

Sergio Fedi

Re: Pharo Video Tutorial: Package Tags

> So getting back to Pharo's tags, I like the fact that there are some common namings, such as many packages will have tags like "Examples", or "Tests", however I still fail to see why would you want to put one class into multiple tags and what the benefit would be.

In my case I have a hard time dealing with hierarchical categorizations, I haev plenty of aspects of my code that runs accross in different ways.

One case is the Model/Web/Application vs Tests, which they can be combined orthogonally.

Another aspect is that I have classes that belong to different layers: Application, Interface-Web, Interface-Windows, Interface-CommandLine, Commands, Model, Persistence

But them several of these classes belong to different "modules" or sets of functionality: Clients, Providers, Administration, Production

With a Tag scheme, I can arbitrarily browse:

All commands that are in the Provider module

Persistence Tests

Classes from Production and Persistence (which should be empty)

Offray

Re: Pharo Video Tutorial: Package Tags

In reply to this post by Sean P. DeNigris

+1 to subpackages as denomination for tags if they're going to be used
only to organize things hierarchically inside a package instead of used
across packages.

Cheers,

Offray

On 03/06/15 13:42, Sean P. DeNigris wrote:

> Sergio Fedi wrote
>> If something is a tag, then you should be able to apply multiple tags to
>> something.
>>
>> If not, then they are, as you say, subpackages.
> Agreed. Actually, tags are more interesting as they would be much more
> valuable to users, who want a logical domain view of the system. Currently,
> the package tree we provide is more a Package Browser than a System Browser.
>
> And... tags are orthogonal to packages. The way we use them, sub-packages
> seems more correct.
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Pharo-Video-Tutorial-Package-Tags-tp4830133p4830290.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Thierry Goubier

Re: Pharo Video Tutorial: Package Tags

In reply to this post by Sergio Fedi

Le 06/06/2015 14:57, Sergio Fedi a écrit :

> > So getting back to Pharo's tags, I like the fact that there are some
> common namings, such as many packages will have tags like "Examples", or
> "Tests", however I still fail to see why would you want to put one class
> into multiple tags and what the benefit would be.
>
> In my case I have a hard time dealing with hierarchical categorizations,
> I haev plenty of aspects of my code that runs accross in different ways.
>
> One case is the Model/Web/Application vs Tests, which they can be
> combined orthogonally.
>
> Another aspect is that I have classes that belong to different layers:
> Application, Interface-Web, Interface-Windows, Interface-CommandLine,
> Commands, Model, Persistence
> But them several of these classes belong to different "modules" or sets
> of functionality: Clients, Providers, Administration, Production
>
> With a Tag scheme, I can arbitrarily browse:
>
> All commands that are in the Provider module
> Persistence Tests
> Classes from Production and Persistence (which should be empty)

At the moment, tags are a bit strict (i.e. hierarchically included with
packages) because of their relation with system categories (one per class).

But elsewhere in the system (i.e. packages) they aren't that significant
(for example, they don't appear in packages).

So, we could do what you say (allow for multiple tags to a class) in a
compatible way with system categories with a slightly different syntax
(and some changes to RPackage):

a category of: PackageName-Interface/Windows

Would say that those classes belong to tags Interface and Windows

The system browser could just then either parse the category (split by
$- for the package name, then split by $/ to get multiple tags) or rely
on RPackage to do so.

Thierry