[squeak-dev] MC scories in Object's DependentsFields

H. Hirzel hannes.hirzel at gmail.com
Tue Jan 22 10:42:11 UTC 2013

So let's add the comment we have as of now.

Is the question/answer form OK? I'd like as well to include the remark
that Bert sees this as a OO example worth  for code reading.

What we have as comment as of now is quite revealing, I think it will
help people having a head-start reading Monticello code.

Nicolas, any further immediate questions  regarding Monticello we
should include?

I think a longer writeup about the design in one class comment is
easier handle then spreading out the comment to various places. We can
just refer to it from the other class comments.

Often one is discouraged to even start reading code because one does
not know if it is worth spending two hours just to find out that one
has just wasted time and not found out anything worthwhile.

It is actually exciting to see that we have a model of Smalltalk code
in Monticello. Let's investigate this more. It seems that it might be
a hidden treasure.  :-)


On 1/22/13, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> IMO, the fact that code is crystal clear is not a good reason to omit
> documentation.
> There is also an effect of volume.
> The fact that MC is huge makes it impossible to embrass its overall
> structure for a newcomer.
> Often in Smalltalk, we pick up a very small detail, like this case of
> cleaning a cache, and have to reconstruct a mental image of MC
> architecture from bottom-up. Where is this class used, and its cache?
> Class comments at least help a lot along this track.
> I learned Smalltalk ith st-80 v2.3 and st-V, and I can say that
> comments were not omitted in these distributions. Though the volume of
> code was well below current Squeak trunk.
> I'm not sure that increase of volume combined with lack of coments
> makes beginner's life easier.
> Nicolas
> 2013/1/22 Bert Freudenberg <bert at freudenbergs.de>:
>> Am 21.01.2013 um 22:29 schrieb "H. Hirzel" <hannes.hirzel at gmail.com>:
>>> Thank you Bert for these concise answers. They will make up a good
>>> bases for the comment.
>>> A follow up question:
>>> At which occasion is a snapshot done and what purpose does it serve?
>> 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.
>> 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.
>> - Bert -
>>> --Hannes
>>> On 1/21/13, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>> On 21.01.2013, at 13:40, "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>>>> And as we are at it
>>>>>   http://bugs.squeak.org/view.php?id=7560
>>>>> Monticello-Base contains the three classes
>>>>> MCDefinition
>>>>> MCPackage
>>>>> MCSnapshots
>>>>> All class comments are empty.
>>>> A definition is a model for Smalltalk code. A package snapshot is a
>>>> collection of these definitions.
>>>>> What is the relationship between MCPackage and PackageInfo.
>>>> MCPackage uses PackageInfo to find out which methods and classes belong
>>>> to a
>>>> package.
>>>>> What does
>>>>>  MCDefinition clearInstances.
>>>>> do?
>>>> It nils out the quick-access cache to its subinstances. #allInstances
>>>> is
>>>> very slow as it needs to scan the whole object memory, whereas
>>>> retrieving an
>>>> instance from the "instances" WeakSet is O(1).
>>>>> Why can this be done safely?
>>>> Because re-using a definition is only a space optimization.
>>>>> What is the impact of doing this?
>>>> When loading/creating another snapshot, the definitions that are in
>>>> both
>>>> snapshots will not be shared but occupy space twice.
>>>> - Bert -
>>>>> --Hannes
>>>>> On 1/21/13, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>>>>> wrote:
>>>>>> Trying to chasePointers of MCDefinition allSubInstances, I saw
>>>>>> several
>>>>>> instances of MCPatchBrowser, MCVersionInspector, ...
>>>>>> Though no such window is opened in my World, what's up?
>>>>>> If I chase pointers of one of these ghost MCPatchBrowser keys, I see
>>>>>> nothing but the opened inspectors and ObjectDependentsFields...
>>>>>> I guess this must be exactly the same bug as
>>>>>> http://bugs.squeak.org/view.php?id=7119 (see my own comments).
>>>>>> The key of DependentsFields are weak, so they should be reclaimed.
>>>>>> But what if the value points somehow to the key (no matter how deep)?
>>>>>> Well, the key will never be reclaimed then.
>>>>>> I don't feel comfortable with these dependencies... It's a nest of
>>>>>> problems.
>>>>>> In MVC, the dependents were maintained in model, so a cycle would be
>>>>>> garbageCollected more easily...
>>>>>> Nicolas

More information about the Squeak-dev mailing list