On 30 July 2012 11:35, David T. Lewis <lewis at mail.msen.com> wrote:
> On Sat, Jul 28, 2012 at 02:33:59PM -0700, Bert Freudenberg wrote:
>> On 28.07.2012, at 13:39, Bert Freudenberg wrote:
>>
>> > Guys, please take a step back. There is no "code".
>> >
>> > Q: The comment of a class is held where?
>> > A: An instance variable of the class object.
>> >
>> > Q: The comment of a package should be held where?
>> > A: An instance variable of the package object.
>> >
>> > Everything else is just a tools issue. If we had a browser for packages, it would allow editing the package comment.
>> >
>> > Right now the browser to edit packages is Monticello. And it would work just like editing the preambles and postscripts of a package. It's a trivial addition really. As far as Monticello is concerned, it would just be another kind of definition.
>> >
>> > Guess I should just code it up ...
>> >
>> > - Bert -
>>
>> Done. Very straight-forward. Take a peek in the inbox, PackageInfo-Base-bf.65 and Monticello-bf.513.
>>
>> You need to press the "Scripts" button in MC to edit the comment. We can decide on a better label later.
>>
>> Yay/nay?
>>
>
> Yay from me.
>
> Subclassing PackageInfo just to add a comment seems wrong, and it is
> certainly not something that I would ever think of doing. Keeping the
> package comments on SqueakMap does not seem right. Bert's explanation
> and implementation make sense to me, so +1.

In other words you feel that the sort of information that goes in a
package's comment is not the sort of information that goes in
SqueakMap? That sounds sensible: the SM description for Control (to
use an arbitrary example) would say "Control provides mechanisms for
creating, composing and calculating with delimited continuations". In
other words, what it's for, why you should care, and so on. Its
PackageInfo comment would explain the basic architecture,
implementation strategies, and the like.

frank

> Dave
>
>
>