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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to