MC scories in Object's DependentsFields
Locked
MC scories in Object's DependentsFields
 
|
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 |
Re: MC scories in Object's DependentsFields
|
|
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. What is the relationship between MCPackage and PackageInfo. What does MCDefinition clearInstances. do? Why can this be done safely? What is the impact of doing this? --Hannes On 1/21/13, Nicolas Cellier <[hidden email]> 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 > > |
Re: MC scories in Object's DependentsFields
|
|
+1 I had the same questions coming after a quick browse few hours ago...
I have another one: why doesn't MCTool inherits from Model? 2013/1/21 H. Hirzel <[hidden email]>: > 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. > What is the relationship between MCPackage and PackageInfo. > > What does > MCDefinition clearInstances. > do? > > Why can this be done safely? What is the impact of doing this? > > --Hannes > > > On 1/21/13, Nicolas Cellier <[hidden email]> 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 >> >> > |
Re: MC scories in Object's DependentsFields
|
|
In reply to this post by Hannes Hirzel
On 21.01.2013, at 13:40, "H. Hirzel" <[hidden email]> 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 <[hidden email]> 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 >> >> > |
Re: MC scories in Object's DependentsFields
|
|
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? --Hannes On 1/21/13, Bert Freudenberg <[hidden email]> wrote: > > On 21.01.2013, at 13:40, "H. Hirzel" <[hidden email]> 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 <[hidden email]> 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 >>> >>> >> > > > |
Re: MC scories in Object's DependentsFields
|
|
Am 21.01.2013 um 22:29 schrieb "H. Hirzel" <[hidden email]>:
> 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 <[hidden email]> wrote: >> >> On 21.01.2013, at 13:40, "H. Hirzel" <[hidden email]> 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 <[hidden email]> 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 > |
Re: MC scories in Object's DependentsFields
|
|
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 <[hidden email]>: > Am 21.01.2013 um 22:29 schrieb "H. Hirzel" <[hidden email]>: > >> 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 <[hidden email]> wrote: >>> >>> On 21.01.2013, at 13:40, "H. Hirzel" <[hidden email]> 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 <[hidden email]> 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 >> > |
Re: MC scories in Object's DependentsFields
|
|
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. :-) --Hannes On 1/22/13, Nicolas Cellier <[hidden email]> 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 <[hidden email]>: >> Am 21.01.2013 um 22:29 schrieb "H. Hirzel" <[hidden email]>: >> >>> 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 <[hidden email]> wrote: >>>> >>>> On 21.01.2013, at 13:40, "H. Hirzel" <[hidden email]> 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 <[hidden email]> >>>>> 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 >>> >> > > |
Re: MC scories in Object's DependentsFields
|
|
In reply to this post by Nicolas Cellier
Maybe we should have a package comment that describe how the whole structure is so it's easier to
get hunch of where to start looking for a certain functionality.
Karl
On Tue, Jan 22, 2013 at 10:23 AM, Nicolas Cellier <[hidden email]> wrote: IMO, the fact that code is crystal clear is not a good reason to omit |
Re: MC scories in Object's DependentsFields
|
|
At the moment we need to put the package comment in a particular class
of the package. A reminder: Squeak does not support package comments, a long standing issue. For an earlier 'package comment' discussion see for example http://forum.world.st/Documentation-What-about-package-comments-td2062634.html More challenging than the question where to put the package comments is actually getting them in the first place. So I'd say let's not get sidetracked in this thread and focus on describing the Monticello package design. So that we can put it into one of the major classes and refer to it from the other important classes. Karl, if you look at the Monticello classes what questions do you have? --Hannes On 1/22/13, karl ramberg <[hidden email]> wrote: > Maybe we should have a package comment that describe how the whole > structure is so it's easier to > get hunch of where to start looking for a certain functionality. > > Karl > > > > > On Tue, Jan 22, 2013 at 10:23 AM, Nicolas Cellier < > [hidden email]> 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 <[hidden email]>: >> > Am 21.01.2013 um 22:29 schrieb "H. Hirzel" <[hidden email]>: >> > >> >> 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 <[hidden email]> wrote: >> >>> >> >>> On 21.01.2013, at 13:40, "H. Hirzel" <[hidden email]> 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 <[hidden email]> >> 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 >> >> >> > >> >> > |
Re: MC scories in Object's DependentsFields
|
|
In reply to this post by Hannes Hirzel
Am 22.01.2013 um 02:42 schrieb "H. Hirzel" <[hidden email]>:
> Is the question/answer form OK? That would be very unusual. I wouldn't like it. > I'd like as well to include the remark that Bert sees this as a OO example worth for code reading. That would not belong in a comment. Put it in a welcome workspace or blogpost or book. - Bert - |
Re: MC scories in Object's DependentsFields
|
|
Hey, we have HelpSystem installed by default in trunk images, haven't we?
Nicolas 2013/1/22 Bert Freudenberg <[hidden email]>: > Am 22.01.2013 um 02:42 schrieb "H. Hirzel" <[hidden email]>: > >> Is the question/answer form OK? > > That would be very unusual. I wouldn't like it. > >> I'd like as well to include the remark that Bert sees this as a OO example worth for code reading. > > That would not belong in a comment. Put it in a welcome workspace or blogpost or book. > > - Bert - |
Re: MC scories in Object's DependentsFields
|
|
In reply to this post by Nicolas Cellier
On 22-01-2013, at 1:23 AM, Nicolas Cellier <[hidden email]> wrote: > IMO, the fact that code is crystal clear is not a good reason to omit > documentation. Agreed - comments =/= documentation. Documents explain the overall system, the intent, the usage, where it doesn't (yet) meet the desired results, where to get updates and ask questions, points to places to start looking at code to build an understanding of it, offers example usage that actually makes sense (I know, I'm a dreamer!) and overall should allow someone to use the code/package/application without ever feeling like they need to understand every detail of the implementation. To paraphrase Adele Goldberg - "Without documentation, the code doesn't usefully exist. If the code doesn't exist, why exactly did we pay you for it?" tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Ubi dubium ibi libertas |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |