On 28 May 2015, at 09:02, Nicolai Hess <nicolaihess@web.de> wrote:

Hi Sergio,

2015-05-28 1:56 GMT+02:00 Sergio Fedi <sergio.fedi@gmail.com>:
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.