Smalltalk › Pharo › Pharo Smalltalk Developers

Beyond RPackages: RPackageTag and DynamicGroup

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Sergio Fedi

Beyond RPackages: RPackageTag and DynamicGroup

Hi list!

As we are adding comments to Packages in Pharo, we stumbled upon the fact that there are other creatures present in the package list.

These are:

RPackageTag, which models the tags under the package

DynamicGroup, which model the dynamic categories of LastModifiedClasses, MostViewedClasses and Work

Objects of these classes WILL have to understand the accessor #comment

1 - How do we want RPackageTag and DynamicGroup to handle #comment and #comment: ?

2 - Are there any other classes present in that list we are not aware of?

Some options we can consider:

a - Hardcode in an generic answer to #comment, do nothing on #comment, leave them be for now

b - Have the object behave as a RPackage, it can have a persistent comment. In this case, where do we save that data?

Since the Package Comments case is taking so long, and to keep the scope of the case in check, we are incline to handle both classes with option a.

But we wanted to check with the list first, just in case.

Ok, now let's hear you feedback.

stepharo

Re: Beyond RPackages: RPackageTag and DynamicGroup

Le 28/5/15 01:56, Sergio Fedi a écrit :

Hi list!

As we are adding comments to Packages in Pharo, we stumbled upon the fact that there are other creatures present in the package list.

These are:

RPackageTag, which models the tags under the package

DynamicGroup, which model the dynamic categories of LastModifiedClasses, MostViewedClasses and Work

Objects of these classes WILL have to understand the accessor #comment

1 - How do we want RPackageTag and DynamicGroup to handle #comment and #comment: ?

2 - Are there any other classes present in that list we are not aware of?

Some options we can consider:

a - Hardcode in an generic answer to #comment, do nothing on #comment, leave them be for now

I would just return an empty string.
I think that the problem is that the item list elements should be customized to not send the messages comment to the
wrapped items (Tag, DynamicGroup....).

Stf

b - Have the object behave as a RPackage, it can have a persistent comment. In this case, where do we save that data?

Since the Package Comments case is taking so long, and to keep the scope of the case in check, we are incline to handle both classes with option a.

But we wanted to check with the list first, just in case.

Ok, now let's hear you feedback.

Marcus Denker-4

Re: Beyond RPackages: RPackageTag and DynamicGroup

In reply to this post by Sergio Fedi

On 28 May 2015, at 01:56, Sergio Fedi <[hidden email]> wrote:

Hi list!

As we are adding comments to Packages in Pharo, we stumbled upon the fact that there are other creatures present in the package list.

These are:

RPackageTag, which models the tags under the package
DynamicGroup, which model the dynamic categories of LastModifiedClasses, MostViewedClasses and Work

Objects of these classes WILL have to understand the accessor #comment

1 - How do we want RPackageTag and DynamicGroup to handle #comment and #comment: ?

The tag could just return the comment that is defined for it’s package. The Nautilus groups maybe could

return a description on what they do and how they work?

Marcus

Nicolai Hess

Re: Beyond RPackages: RPackageTag and DynamicGroup

In reply to this post by Sergio Fedi

Hi Sergio,

2015-05-28 1:56 GMT+02:00 Sergio Fedi <[hidden email]>:

Hi list!

As we are adding comments to Packages in Pharo, we stumbled upon the fact that there are other creatures present in the package list.

These are:

RPackageTag, which models the tags under the package
DynamicGroup, which model the dynamic categories of LastModifiedClasses, MostViewedClasses and Work

Objects of these classes WILL have to understand the accessor #comment

1 - How do we want RPackageTag and DynamicGroup to handle #comment and #comment: ?

RPackageTags knows about the package they are in, they could answer

self package comment

I have no objections to add comments to the Groups.

2 - Are there any other classes present in that list we are not aware of?

No.

Some options we can consider:

a - Hardcode in an generic answer to #comment, do nothing on #comment, leave them be for now
b - Have the object behave as a RPackage, it can have a persistent comment. In this case, where do we save that data?

Since the Package Comments case is taking so long, and to keep the scope of the case in check, we are incline to handle both classes with option a.

Another way:
The elements in the package/group list can be wrapped by an PackageTreeSelection. We can make the distinction at this

level.

PackageTreeTagSelection -> delegate to package

PackageTreePackageSelection -> set/get package comment

PackageTreeGroupSelection -> ignore

But be aware, not all operations in Nautilus initialize the current selection correctly.

Sometimes the selected package item is a PackageTreeSelection, sometimes it is just the RPackage/-Tag/Group item.

This is a bug not yet resolved.

But we wanted to check with the list first, just in case.

Ok, now let's hear you feedback.

EstebanLM

Re: Beyond RPackages: RPackageTag and DynamicGroup

On 28 May 2015, at 09:02, Nicolai Hess <[hidden email]> wrote:

Hi Sergio,

2015-05-28 1:56 GMT+02:00 Sergio Fedi <[hidden email]>:
Hi list!

As we are adding comments to Packages in Pharo, we stumbled upon the fact that there are other creatures present in the package list.

These are:

RPackageTag, which models the tags under the package
DynamicGroup, which model the dynamic categories of LastModifiedClasses, MostViewedClasses and Work

Objects of these classes WILL have to understand the accessor #comment

1 - How do we want RPackageTag and DynamicGroup to handle #comment and #comment: ?

RPackageTags knows about the package they are in, they could answer

self package comment

I have no objections to add comments to the Groups.

I do :)

Groups are Nautilus exclusive structures, not part of the system. Why would you want to add comments there?

As Stef said, in that case I, to make groups polymorphic, I would just answer an empty string.

2 - Are there any other classes present in that list we are not aware of?

No.

Some options we can consider:

a - Hardcode in an generic answer to #comment, do nothing on #comment, leave them be for now
b - Have the object behave as a RPackage, it can have a persistent comment. In this case, where do we save that data?

Since the Package Comments case is taking so long, and to keep the scope of the case in check, we are incline to handle both classes with option a.

Another way:
The elements in the package/group list can be wrapped by an PackageTreeSelection. We can make the distinction at this
level.
PackageTreeTagSelection -> delegate to package
PackageTreePackageSelection -> set/get package comment
PackageTreeGroupSelection -> ignore

But be aware, not all operations in Nautilus initialize the current selection correctly.
Sometimes the selected package item is a PackageTreeSelection, sometimes it is just the RPackage/-Tag/Group item.
This is a bug not yet resolved.

But we wanted to check with the list first, just in case.

Ok, now let's hear you feedback.

Sergio Fedi

Re: Beyond RPackages: RPackageTag and DynamicGroup

Thanks for the feedback.

(Thanks Nicolai for confirming that)

I understand all of the arguments.

Somethings to spur things up:

An argument in favor of having both classes handle comments is that from a user perspective:

DynamicGroup - It's good to know the criteria under which classes are grouped (sometimes it's not evident, and sometimes the details are important)

(Personally I have no idea of Work criteria to list classes, and have no idea of the details of the other two)

RPackageTag - Although we can fall back to the package comment, the Tag is there for something. There is a communicational intention for the Tag been there.

In the case of "Tests", it's quite clear. But sometimes, not so much.

Having said all of these, I'm inclined to follow this path:

1 - Make the wrappers send/not send #comment to its wrapee.

2 - Let all hell break loose and force the wrapping bug to be fixed

3 - Leave for future work to add comments to DynamicGroups and Tags

Note: I said "I" because Kasper may differ on this and I didn't want to put words in his mouth

Ben Coman

Re: Beyond RPackages: RPackageTag and DynamicGroup

On Thu, May 28, 2015 at 5:48 PM, Sergio Fedi <[hidden email]> wrote:
> (Personally I have no idea of Work criteria to list classes, and have no
> idea of the details of the other two)

Neither do I. Never used them. Now I wonder if when you define a new
group, you might also define a filter and the existing groups use that
facility, such that you could inspect and existing group to see its
definition.

cheers -ben

Sergio Fedi

Re: Beyond RPackages: RPackageTag and DynamicGroup

On Thu, May 28, 2015 at 9:39 AM, Ben Coman <[hidden email]> wrote:

On Thu, May 28, 2015 at 5:48 PM, Sergio Fedi <[hidden email]> wrote:
> (Personally I have no idea of Work criteria to list classes, and have no
> idea of the details of the other two)

Neither do I. Never used them. Now I wonder if when you define a new
group, you might also define a filter and the existing groups use that
facility, such that you could inspect and existing group to see its
definition.

This is why we need comments on DynamicGroups