Le 18 mai 2015 à 15:17, Sergio Fedi a écrit : > > > 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.
This example looks strange to me. It means you put some kind of changelog (or upgrade instructions) of your package in the package comments. But you do not know from which version the user will upgrade. Will you keep all upgrade instructions? > 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. Maybe you do not need a specific part for such information because I think (hope) most packages will not require such kind of information. > > > > 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) Could you describe me how Dolphin does and/or if you have some screenshots? > So, to clear thing up, > what are you saying? 2 - Make more methods for other metadata such as [...] you may concatenate this information into the package comment for the display part even if not yet editable. > > 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?
smime.p7s
Description: S/MIME cryptographic signature
