Le 15 mai 2015 à 22:39, 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.
But that doesn't mean it's the right choice :)
The thing is that we can go full speed with this and make comments for:
oneLineSummary longDescription usageDescription
ok
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.
authorshipText contactDescription creationDate lastUpdateDate
This information is meta-information on a package and should not be lost in the package comment.
and a long etcetera
Or we could go beyond this and define set of properties, each one with it's priority to be shown and some way to define the order of rendering.
Problem is: where to draw the line?
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 ... MyPackage>>aMetadata MyPackage>>aMetadata: value 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. Regards, Christophe