Independent of package comments, the ManifestClasses are a good idea I think. I also think they have not yet found their final design. Let me summarize my impressions so far (perhaps this need to go to a different thread).
a) All package manifests are subclasses of "PackageManifest" - good idea. b) The principle of storing the manifest properties as literals in methods is surprising, but has its advantages. However, no general functionality for storing those values seems to be in place. c) The class "TheManifestBuilder" seems to be a key class, and has a lot of functionality for the quality assistant (I presume that is what they are used for - I have not looked in that corner of the system yet). I think the manifest builder need to be split into a family of builders, a general builder which has the functionality to create and query manifest classes, and a set of builders for each (set of) properties of manifest classes. The QualityAssistant would then have its own subclass, and package comments would have its subclass. For now, I believe I will experiment with merely having a package comment category on TheManifestBuilder. -- View this message in context: http://forum.world.st/Package-comments-tp4824353p4825058.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
