David Farber wrote:
> 
> [Request For Implementation]
> 
> I was browsing Robert Hirschfeld's sUnit implementation this past weekend
> and noticed that he did a nice job of commenting the classes. (this is in
> the current update stream right? or did i file this in?) i especially
> appreciated the way he commented the class's instance variables, eg. for
> TestModel:
> 
> Instance Variables:
>         summaryText          <String>
>         detailsText          <String>
>         failureList          <OrderedCollection of: String>
>         errorList            <OrderedCollection of: String>
>         patternHistory       <OrderedCollection of: String>
>         summaryTextM         <PluggableTextMorph | nil>
>         summaryTextV         <PluggableTextView | nil>
>         updateColorSelector  <Symbol>
> 
> this morning i remembered that Doug Way's Whisker browser performs type
> inferencing to display this kind of information when looking at a class
> definition.

Technically, Whisker does type collecting or "type snooping", which is slightly different from type inferencing in that it determines types by examining existing instances in the image, rather than examining source code.  But the end result is similar, you get a reasonable guess of the type.  (Vassili Bykov actually wrote the original type collector which I then added to Whisker, after modifying it a bit.)

Type collecting is nice because it can run quickly, whereas a thorough type inferencer can be pretty slow.  The downside to type collecting is that sometimes there will be no instances of a given class in the image to collect from.  (Although this is often not a problem because as a general rule you're usually editing classes which you're actually running in the image.)  I was thinking about adding Dan Ingalls' simple type inferencer to Whisker as a backup method for when the type collector can't find any instances.  Also, I think Lex Spoon is working on a more thorough type inferencer... I'm not sure what the status of that is.  Anyway, this is sort of a digression from your post.

> Proposal:
> what i would like to see is Whisker's type inferencing capabilites used to
> autogenerate (at least part of the) class comments. i envision
> autogenerating a preamble to the class comments containing the instance
> variables and their types, as shown above in the example of Robert's class
> comments. this preamble would not be editable, and would always be kept up
> to date by the system. (i believe Whisker keeps the type info up to date,
> even as you change the class definition or change a variable's implied
> type.) the preamble would be followed by some sort of delimiter, say:
> 
> ----
> 
> regular, editable class comments would follow the delimiter. any text
> editing above the delimiter would be ignored by an accept of changes made
> to the class comments.

This is a good idea, actually I think Dan's original simple type inferencer put the information in the comment.

Although I think an even better idea might be to put this information (inside double quotes) after the type definition which appears when you first select a class.  That way the information will be more immediately available, rather than having to switch over to the comment to see it.

(I got this idea from a recent thread on comp.lang.smalltalk, in which it was suggested that some sort of double-quoted warning that "THIS CLASS IS NOT YET COMMENTED" should be added at the end of the class definition pane in VisualWorks browsers, which is also an excellent idea for Squeak.  When all else fails, shame people into adding comments. ;-) )

> i think this would be a great feature to add to squeak, especially for
> people coming to Smalltalk from a typed languge. (and if Whisker gets
> mainlined into squeak, so much the better!!)

Some sort of type inferencing or collecting really should be in the base image, I agree... even if it's only 95% accurate, it's a huge help to beginners finding their way around the class library.

- Doug Way
  dway at riskmetrics.com