> > Personally, I do not fear to change the comment implementation later. > > That's what Smalltalk is good at. > > +1. But the most difficult thing is not to change the implementation but all its usage. > if people start to use a feature and you change the way to use it after, it is more difficult to update all users of the feature.
Problem is, this feature is not used now because it doesn't exist. Bottom line is: If the future usage problem is about what to put in the default comment, It's ok for me to change it however we decide. If the future usage problem is about what other metadata we put con the Manifest then it is irrelevant for this issue. > > preInstallComment > > postInstallComment > > what is that? if it is Smalltalk code to run before/after the installation, it should not be in the comment but in a separated method. > Pharo misses a package setUp and tearDown methods. These are comments relating to thing you have to be aware of before installing and after installing the package. For example, a behaviour changed on some objects. A new option on a menu. Another package that does not "get along" with this package. Things that are not code, but are relevant either before or after the loading of a package. > > authorshipText > > contactDescription > > creationDate > > lastUpdateDate > > This information is meta-information on a package and should not be lost in the package comment. Exactly. Except that when you can't put it anywhere else, it usually ends up in the comment. (my argument is: as long as you don't have anywhere else to put certain info, it's better to have it somewhere rather than nowhere, so you could suggest that in the default comment) > > My initial strategy was to have comments and then model the commonalities of all package comments away to the appropiate method/variable/data > > I already started to work on some specific package meta-data. > As I wrote before, for now, I store it in the PackageManifest because Monticello does not have a good support for meta-data. > But anyway, we could just see that as an "implementation details". > What I think is important is not to work directly with the PackageManifest but having an object manipulating it and able to answer to selectors like: > MyPackage>>description > MyPackage>>description: aText We are doing the same thing then. > I work on a spec widget to edit some package meta-data. > Maybe you could do the same to be able to present other meta-data than the package comment from Nautilus. It is more work and can just come for a second version. I think that will be necessary for sure. For now, it seems really easy and straightforward to show comments in Nautilus. It uses the same real state that class comments use. Other metadata, I'm not sure how it would work. That would fall more under the province of a PackageBrowser or something like that. Dolphin has this problem solved in a nice way (I don't know how other Smalltalks solve it) So, to clear thing up, what are you saying? 1 - Don't mention putting other information in the default package comment 2 - Make more methods for other metadata such as [...] 3 - Both, 1 and 2 4 - Other?
