<div>Maybe we should have a package comment that describe how the whole structure is so it's easier to </div>
<div>get hunch of where to start looking for a certain functionality.</div>
<div> </div>
<div>Karl</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div class="gmail_quote">On Tue, Jan 22, 2013 at 10:23 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">IMO, the fact that code is crystal clear is not a good reason to omit<br>documentation.<br>There is also an effect of volume.<br>
The fact that MC is huge makes it impossible to embrass its overall<br>structure for a newcomer.<br><br>Often in Smalltalk, we pick up a very small detail, like this case of<br>cleaning a cache, and have to reconstruct a mental image of MC<br>
architecture from bottom-up. Where is this class used, and its cache?<br>Class comments at least help a lot along this track.<br><br>I learned Smalltalk ith st-80 v2.3 and st-V, and I can say that<br>comments were not omitted in these distributions. Though the volume of<br>
code was well below current Squeak trunk.<br>I'm not sure that increase of volume combined with lack of coments<br>makes beginner's life easier.<br><br>Nicolas<br><br><br>2013/1/22 Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>>:<br>
<div class="HOEnZb">
<div class="h5">> Am 21.01.2013 um 22:29 schrieb "H. Hirzel" <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>>:<br>><br>>> Thank you Bert for these concise answers. They will make up a good<br>
>> bases for the comment.<br>>><br>>> A follow up question:<br>>><br>>> At which occasion is a snapshot done and what purpose does it serve?<br>><br>> A snapshot is how MC models the contents of a package. Saving a package means storing a snapshot of it. Loading means taking another snapshot of what's currently in the image and comparing it to the stored snapshot, then filing in just the differences between the two.<br>
><br>> The MC code base is actually very readable, you should try having a look at it. Nice example of OO design. I found the code to not even need extensive comments, it is perfectly understandable without.<br>><br>
> - Bert -<br>><br>><br>>> --Hannes<br>>><br>>> On 1/21/13, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>>>><br>>>> On 21.01.2013, at 13:40, "H. Hirzel" <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>> wrote:<br>
>>><br>>>>> And as we are at it<br>>>>><br>>>>> <a href="http://bugs.squeak.org/view.php?id=7560" target="_blank">http://bugs.squeak.org/view.php?id=7560</a><br>>>>><br>
>>>> Monticello-Base contains the three classes<br>>>>><br>>>>> MCDefinition<br>>>>> MCPackage<br>>>>> MCSnapshots<br>>>>><br>>>>> All class comments are empty.<br>
>>><br>>>> A definition is a model for Smalltalk code. A package snapshot is a<br>>>> collection of these definitions.<br>>>><br>>>>> What is the relationship between MCPackage and PackageInfo.<br>
>>><br>>>> MCPackage uses PackageInfo to find out which methods and classes belong to a<br>>>> package.<br>>>><br>>>>> What does<br>>>>> MCDefinition clearInstances.<br>
>>>> do?<br>>>><br>>>> It nils out the quick-access cache to its subinstances. #allInstances is<br>>>> very slow as it needs to scan the whole object memory, whereas retrieving an<br>
>>> instance from the "instances" WeakSet is O(1).<br>>>><br>>>>> Why can this be done safely?<br>>>><br>>>> Because re-using a definition is only a space optimization.<br>
>>><br>>>>> What is the impact of doing this?<br>>>><br>>>> When loading/creating another snapshot, the definitions that are in both<br>>>> snapshots will not be shared but occupy space twice.<br>
>>><br>>>> - Bert -<br>>>><br>>>>> --Hannes<br>>>>><br>>>>><br>>>>> On 1/21/13, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
>>>>> Trying to chasePointers of MCDefinition allSubInstances, I saw several<br>>>>>> instances of MCPatchBrowser, MCVersionInspector, ...<br>>>>>> Though no such window is opened in my World, what's up?<br>
>>>>><br>>>>>> If I chase pointers of one of these ghost MCPatchBrowser keys, I see<br>>>>>> nothing but the opened inspectors and ObjectDependentsFields...<br>>>>>><br>
>>>>> I guess this must be exactly the same bug as<br>>>>>> <a href="http://bugs.squeak.org/view.php?id=7119" target="_blank">http://bugs.squeak.org/view.php?id=7119</a> (see my own comments).<br>
>>>>> The key of DependentsFields are weak, so they should be reclaimed.<br>>>>>> But what if the value points somehow to the key (no matter how deep)?<br>>>>>> Well, the key will never be reclaimed then.<br>
>>>>><br>>>>>> I don't feel comfortable with these dependencies... It's a nest of<br>>>>>> problems.<br>>>>>> In MVC, the dependents were maintained in model, so a cycle would be<br>
>>>>> garbageCollected more easily...<br>>>>>><br>>>>>> Nicolas<br>>><br>><br><br></div></div></blockquote></div><br>