Yay sandboxing <div> Yay trivial solve name clashing </div><div> Why hide it <div><br><div>Vat good iss a Dooms Day device</div><div> If You Keep It A Zecret</div><div><br></div><div> Vhy Didn't You Tell Ze VVorld HAH? <---[ Doctor strange love ]</div><div><br></div><div>in my opinion if you make a function in a software</div><div> and don't tell anyone</div><div> you might as well not have made the function</div><div> nobody knows it's in there</div><div>in Smalltalk the code itself often tells anyone</div><div> but in other languages not so much</div><div> consequently they seem to have better documentation some or mostly</div><div>in Smalltalk if a function is dispersed or complex</div><div> such that the code does not speak very well or is muted</div><div> then not spending a few minutes to comment</div><div> ( like Andy Bower used to do for Dolphin</div><div> every single method with a </div><div> one line comment<---[ is priceless ][ no other help is needed ][ mostly ]</div><div> most of the main classes big commented )</div><div> the main Classes with design and or usage notes</div><div> is a crime of wasted effort</div><div>in my opinion</div><div>look at the fact that Dolphin has always been so bullet proof</div><div> with images going for months even years without a crash</div><div> or a memory leak</div><div> and all or most of it made by just one or two guys</div><div> can it be attributed to the comments</div><div> at all</div><div> well i bet you a good big chunk of that success rate can be</div><div> I know those comments contributed a good big chunk </div><div> of my not needing to ask for help with Dolphin</div><div> ever</div><div> such that i got a bad habit of never asking for help</div><div> and was totally spoiled for anything that was not Dolphin</div><div><br></div><div>how about this idea</div> a Class whose only job is to describe some subsystem</div><div> where each of the Methods is just a comment</div><div> or returns a String</div><div> like a little book right in the code</div><div> ( use Pier Seaside Aida Iliad etc if you had a wild hair </div><div> to get fancy )<---[ not needed ]</div><div><div><br></div><div>so up with comments and up with Andy Bower</div><div> is what I'm saying</div><div><br></div><div>and don't hand Google another brick in the wall of their world domination</div><div> by hiding comments out on the internet</div><div><br></div><div> unless you link to it from comments in the code</div><div><br></div><div> in that case every single Class involved should contain such</div><div> a link in its comment to its comment out on the web</div><div> and Methods could have comment links to specific places</div><div> in the web pages where it is commented</div><div> or you hate the users </div><div> and you hate cheaply gotten Maybe wider Smalltalk usage</div><div> in my opinion</div><div> </div><div><br>On Saturday, September 24, 2016, Stéphane Rollandin <<a href="mailto:lecteur@zogotounga.net">lecteur@zogotounga.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It was pretty difficult for Colin Putney to perform the heart surgery<br>
necessary to get Environments into the image in the first place. The<br>
capabilities that Environments enable are pretty dang awesome, and it's<br>
a crying shame that people either don't see these capabilities<br>
(sandboxing, trivial resolution of class name clashes are the START of<br>
things) or (more likely) simply haven't had the time to build the<br>
_missing tooling support_ to make Environments work to their fullest.<br>
</blockquote>
<br>
Where is the canonical documentation for Environments, where I would expect to find an exposition of its overall architecture, plus a detailed tour of its most important classes and methods, along with a couple of examples showing how to use it?<br>
<br>
Stef<br>
<br>
<br>
</blockquote></div></div></div>