[squeak-dev] Documentation/Comment per package

Dale Henrichs dhenrich at vmware.com
Sun Jul 29 17:33:15 UTC 2012

It seems a bit much to require the creation of a subclass of PackageInfo for your project just to supply a package comment ... 

I understand your point that without tool support it's kind of a moot point... the tool (whatever and where ever it may be) will probably drive the question of "where to store the comment":

  - do you crack the zip file to get the comment?
  - do you crack the zip file and reify the definitions?
  - something else?

If you have a package comment it would make sense to display the comment on SqueakSource, SqueakMap, in the image, etc....


----- Original Message -----
| From: "Chris Muller" <ma.chris.m at gmail.com>
| To: "Dale Henrichs" <dhenrich at vmware.com>
| Cc: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Sent: Sunday, July 29, 2012 10:05:20 AM
| Subject: Re: [squeak-dev] Documentation/Comment per package
| > You have to agree that a `package comment` belongs with the package
| > and should travel where ever the package goes ...
| Yeah that's a good responsibility for a PackageInfo, but until I
| understand how it would interplay with IDE tools in a useful way,
| simply a message implementation seems enough.
|     PackageInfo>>#comment
|          ^ String empty
| and subclasses can override if they wish.
| With this approach you get all the comment versioning / diffing etc.
| for "free" vs. Berts approach the comment is a "special" attribute of
| the PI that is "hidden" from all of the other attributes such as
| #license, #authors, #tutorial, etc.  For THOSE attributes, go to the
| PackageInfo class browser and update them, but for the #comment, go
| somewhere else because it's stored in a MC definition.
| So, it's an inconsistent treatment of PI attributes that I have
| trouble understanding why and would not want to try to explain to a
| newbie..
| Regards,
|   Chris

More information about the Squeak-dev mailing list