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.
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.
On 28 May 2015, at 01:56, Sergio Fedi <sergio.fedi@gmail.com> 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
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.
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.
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 <mailto: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.
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
On Thu, May 28, 2015 at 5:48 PM, Sergio Fedi <sergio.fedi@gmail.com> 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
On Thu, May 28, 2015 at 9:39 AM, Ben Coman <btc@openinworld.com> wrote:
On Thu, May 28, 2015 at 5:48 PM, Sergio Fedi <sergio.fedi@gmail.com> 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
participants (6)
-
Ben Coman -
Esteban Lorenzano -
Marcus Denker -
Nicolai Hess -
Sergio Fedi -
stepharo