You know, it would be nice to get all this information even if someone
has already written a comment.  It would be especilaly useful, if the
comment sucks, and you are trying to rewrite it :)

Perhaps the 'comment' pane should simply have two parts: one part that
is hand-written, and one part that is auto-generated.  Make it more of a
"summary" page than just a "comment".

Lex



"Ivan Tomek" <ivan.tomek at acadiau.ca> wrote:
> I suggest appending subclass responsibilities as well.
> 
> Ivan
> 
> > We can pre-fill the template with variable names at least (see
> > attached)
> > 
> > --Vassili
> > 
> > > -----Original Message-----
> > > From: Dan Ingalls [mailto:Dan.Ingalls at disney.com]
> > > Sent: Wednesday, February 09, 2000 9:13 PM
> > > To: squeak at cs.uiuc.edu
> > > Subject: Re: Class comments (was Re: ProtoObject?)
> > > 
> > > 
> > > Stefan Matthias Aust <sma at 3plus4.de> (and not I -- sorry) wrote...
> > > 
> > > >However, we should first agree upon a common format.
> > > 
> > > Here is a first crack at this, both as a template for criticism and
> > > suggestions, and as a piece of code you can try out.  I had some fun
> > > today trying to generate the structure with types automatically
> > > (that was the heh-heh), and, as type inference workers are used to
> > > saying, "It turned out to be harder than I thought." (*).
> > > 
> > > 	- Dan
> > > 
> > > Here's the template...
> > > -------------------
> > > !ClassDescription methodsFor: 'accessing' stamp: 'di 2/9/2000
> > > !17:54'!
> > > comment
> > > 	"Answer the receiver's comment. (If missing, supply a template) "
> > > 	| aString | 	aString _ self theNonMetaClass organization
> > > classComment. 	aString isEmpty ifFalse: [^ aString]. 	^ 'Main
> > > comment stating the purpose of this class and relevant relationship
> > > to other classes.
> > > 
> > > Possible useful expressions for doIt or printIt.
> > > 
> > > Structure...
> > > instvar1 		type -- comment about the purpose of instvar1
> > > instvar2 		type -- comment about the purpose of instvar2
> > > 
> > > Any further useful comments about the general approach of this
> > > implementation.'
> > > ! !
> > > --------------------
> > > (*) Actually it was easy, it just didn't do quite as well as I had
> > > hoped. If anyone is interested I can send you the code. It collects
> > > all selectors sent to each instVar, and then computes the union of
> > > highest classes that implement that full set. I think that with info
> > > from stores, and possibly == tests, it would do a lot better.
> > > 
> > > 
> 
> 
> 
> Dr. Ivan Tomek,
> Jodrey School of Computer Science
> Acadia University
> Nova Scotia, Canada
> fax: (902) 585-1067
> voice: (902) 585-1467
> e-mail: ivan.tomek at acadiau.ca