Le 7/5/15 17:04, Kasper Osterbye a écrit :
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).
What you should see is that originally the PackageManifest did not exist so
Manifest classes should not hold behavior. They are just data container.
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.
Why not :)
But you can packaged methods in the PackageManifestBuilder so I'm not
sure that we need
different subclasses.
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.
