On Thursday, October 30, 2003, at 04:17 PM, Daniel Vainsencher wrote:

> I agree with Doug that the ideal solution would
> - have the comment visible
> - not change the class creation messages (have you considered file 
> outs?
> compatibility with older images? other dialects?)
> - not have a notifier on every uncommented class. The idea of ask for a
> comment when you've changed a class sounds nice...
>
> Lets start with something that is more informative but has no bad
> effects. We can always decide to be more pushy later.

I agree with Daniel. :-)  (He made the points more specific.)

- Doug


> Daniel
>
> Karl Ramberg <karl.ramberg at chello.se> wrote:
>>
>>
>> Markus Gaelli wrote:
>>>
>>> Hi Doug,
>>>
>>>> This is looking better, although I think I prefer having the comment
>>>> show up in double-quotes below the template as in your previous
>>>> changeset, rather than extending the template method to
>>>> #subclass:instVarNames:...comment:, for a couple of reasons:
>>>>
>>>> - It looks a bit better visually to have a multi-line comment start 
>>>> on
>>>> a new line (with an extra cr in between).
>>> So why not
>>>
>>> Class >>
>>>         instanceVariableNames: someVarNames
>>>         classVariableNames: someClassNames
>>>         poolDictionaries: somePoolDics
>>>         category: categoryName
>>>         comment:
>>> aCommentText
>> This is easy to fix. It's just to ass a extra cr.
>>>
>>> This shows in the creation method of a class that
>>> it is _essential_ for it to have comments.
>>
>>>> - You have to worry about escaping or handling extra single quotes
>>>> when accepting a new comment in the definition pane.  Hm, it looks
>>>> like this is handled with some sort of magic in your changeset, but
>>>> this causes some weirdnesses, such as if you put a space after
>>>> comment: (to make it consistent with the other parameters), it 
>>>> inserts
>>>> a new single-quote.
>>> I think this is a solvable technical problem, just keep the text
>>> as long as Text as possible, it was not needed until
>>> now and can be done in a more elegant and possibly
>>> more error-free way than I did in my little hack.
>>>> Also, I think the inform: pop-up isn't as necessary if we have the
>>>> comment in the definition pane, as long as there is some warning 
>>>> text
>>>> if the comment is missing.  The pop-up message unfairly punishes
>>>> innocent newbies who simply want to browse code, and will probably
>>>> scare people away. :)
>>> I think that Karl wants to put this to "default on" only in
>>> "images in-between" so that would be o.k. for me.
>> Exactly. Running in alpha and beta is only for daredevils:-)
>>>>
>>>> So, I'd personally be happy to approve a changeset which:
>>>>
>>>> - Has the inform pop-up and preference removed.
>>>> - Shows the class comment (in read-only mode)
>>> I believe that Karl and me had both the idea to make it writable
>>>   in the class definition pane independent from each other...
>>> Still think that this would lower the barrier to write comments,
>>> and this is what this change-sets are all about, no?
>> Yes, I think authoring should always be on.
>>>
>>>> - If there is no class comment, the quoted part in the definition 
>>>> pane
>>>> would say something like "This class has no comment!"
>>> Yep, that should be the empty/ default comment.
>> Fixed.
>>>> - Escape any double-quotes in the comment by doubling them in the
>>>> definition pane. (otherwise a class comment containing double-quotes
>>>> will mess things up when you add instvars, etc.
>>> Don't know about this one right now.
>> I'll look into it.
>>> Karl?
>>>
>>> Markus
>>>
>>>>>>> The snag with both is that the comments are in read only
>>>>>>> mode but in 'comment mode'.
>>>>>>> I'm not sure how to fix that.
>>>>>>>
>>>>>>
>>>>>> I did a little hack, which should do the trick...
>>>>>> though not as I naively thought by enhancing
>>>>>> Class with something like >> subclass: '' instVarNames: '' (...)
>>>>>> comment: ''
>>>>>>
>>>>>> The reason is, that the Class >> classComment: '' expects a text 
>>>>>> and
>>>>>> not
>>>>>> a string. (' in strings are ugly to write and read...)
>>>>>>
>>>>>> So I hacked
>>>>>> Browser >> defineClass: defString notifying: aController
>>>>>>
>>>>>> which is already to long....:-(
>>>>>>
>>>>>> I still reformated it like it could be a method sent to class,
>>>>>> maybe this is missleading?
>>>>>>
>>>>>> Attention: I did not look into timestamps issues of the comment, 
>>>>>> so
>>>>>> this might be wrong.
>>>>>> Also the comment does not update while on the class side...
>>>>>> Also no tests.
>>>>>>
>>>>>> So there is room for improvement... ;-)
>>>>>>
>>>>> Thanks, this is starting to look good.
>>>>>
>>>>> I fixed a issue with a single quote being added to the end of each
>>>>> comment.
>>>>>
>>>>> Karl
>>>>>
>>>>> <NagIfNoClassComment.9.cs.gz>
>>>>
>>>>