<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Jaromir --<div><br></div><div>You can also append another longer comment to the end of that method. There are examples of this in the image. Somewhere. :-)</div><div><br></div><div>I would rather not remove such information too far from the method itself.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 30.05.2022 02:33:37 schrieb tim Rowledge <tim@rowledge.org>:</p><div style="font-family:Arial,Helvetica,sans-serif">My suggestion is that notes about details of the method should be method comments until they get really long. If that happens I would expect that quite a few related methods might have need of extensive commentary too and in that case it would be smart to add a help page to explain the whole thing. <br>If the comments are too long for the top of the method it doesn't hurt to have more at the bottom.<br><br>> On 2022-05-29, at 3:38 PM, Jaromir Matas <mail@jaromir.net> wrote:<br>> <br>> John,<br>> Thanks for your reply. It was my initial idea to possibly use comments but there’s few issues with that approach IMO:<br>> 1) creating a version for each comment change may be counterproductive (too many versions, the method authorship - it’s better to have fewer versions with easily identifiable authors)<br>> 2) only core developers could update trunk comments; I wouldn’t want to place that burden on anybody<br>>  <br>> But yeah, maybe I could try to put some more stuff and examples as a comment after the code. But a more informal but easily reachable place would still be nice.<br>>  <br>> Best,<br>> Jaromir<br>>  <br>> --<br>> Jaromír Matas<br>> mail@jaromir.net<br>>  <br>> From: John-Reed Maffeo<br>> Sent: Monday, May 30, 2022 0:04<br>> To: The general-purpose Squeak developers list<br>> Subject: Re: [squeak-dev] Note sharing inside Squeak?<br>>  <br>> jaromir,<br>>  <br>> Who said comments should be terse and polished?<br>>  <br>> It would be more helpful to people like myself (still a nube after 30+ years) to see a long, complex entry into a method's comment than no comment at all! Putting comments in some other place is counter productive in my mind. <br>>  <br>> Why not put a usage example into comments or the body of the text itself?<br>>  <br>> - jrm<br>>  <br>> On Sun, May 29, 2022 at 12:56 PM Jaromir Matas <mail@jaromir.net> wrote:<br>> Hi all,<br>> In your experience, what would be a good place to *share* more detailed information about e.g. a method: like why I had to include this line and that check, which situations must be taken into account, alternative approaches, examples, references to tests etc etc. Ideally reachable from the image. Would such "notesharing" be welcome or rather confusing or even conterproductive? Often I forget why I did this and that and have to check my notes (if I'm lucky to have made them AND find them). I'm aware method comments are definitely not the place; they are meant to be rather terse and polished. Squeak wiki? Squeak Help? They’d have to be linked somehow to the methods, I imagine, to be useful in this regard…<br>> Any suggestion welcome :)<br>> Best,<br>> Jaromir<br>>  <br>> --<br>> <br>> Jaromír Matas<br>> <br>> mail@jaromir.net<br>> <br>>  <br>>  <br>> <br>> <br>> -- <br>> John-Reed Maffeo<br><br><br>tim<br>--<br>tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim<br>Common sense – so rare it’s a goddam superpower<br><br><br></mail@jaromir.net></mail@jaromir.net></div></blockquote></div>