Concerning method categories: VIsualAge Smalltalk manages without them. Of all the Smalltalk systems available to me, it's the only one where I don't enjoy using the browser. It carves up the world of methods another way, which I find of little or no help. That in no way detracts from it being a solid system fit for its intended uses.
GNU Smalltalk uses <category: 'whatever'> pragmas to put methods into categories. Used consistently and well, method categories are not only a navigation aid, helping you to find methods you do not know the names of, but a helpful documentation aid. For example, #runningMeans: is in the 'summarising' category. In my Smalltalk, that means - it inspects every element of the collection - it does not change the collection - the result is somehow a summary or distillation of the elements Of course, to get the most from method categories, the method categories need to be documented, and you need to keep them as up to date as any other part of the source code. I can say that the discipline of trying to come up with meaningful categories and use them consistently has improved the quality of my code. On Mon, 13 Apr 2020 at 00:38, Cédrick Béler <cdric...@gmail.com> wrote: > > Fully agree on proper names. > > === I don’t know if this is because of free confinement time but I can keep > on asking questions so I share some I hope will make sense (for the sake of > discussion). > > For instance, I'm wondering if tests on conditions so as to raise proper > exceptions is a good practice (for instance if the width object does not > make sense, like a float) #doesNotMakeSense btw would be a cool name for the > « maybe » cases Richard was talking. > > Then I asked myself what are the drawbacks (especially on performance) on > adding extra information to source code (a bit like longer variable names) ? > > There is the raw code and the sources code file that helps separating > concerns. At least we don’t mind at all having longer literals (variables > names, …). > > I cannot help is what about pragmas. I kind see roughly how they work. But is > it possible to distinguish between runtime / source only pragmas (not sure > I’m clear here but it seems to me that some are important for documentation > purposes that are not needed at runtime) ? > > Also, I’ve never really liked method categories. I don’t really see how there > are implemented but they don’t feel nice to me. > Could they be only pragmas ? > > > > > > Happy eater Sunday, stay all preserved (sad day for the game of life), > > Cédrick > > > > > Le 12 avr. 2020 à 14:22, Sven Van Caekenberghe <s...@stfx.eu> a écrit : > > > > > > > >> On 12 Apr 2020, at 13:53, Cédrick Béler <cdric...@gmail.com> wrote: > >> > >> Beautiful ^^ > > > > I also like it. > > > > But why the single letter variable names ? Why not: > > > > SequenceableCollection>>#runningMeans: width > > | means sum index | > > means := Array new: self size - width + 1. > > sum := 0. > > 1 to: width do: [ :each | > > sum := sum + (self at: each) ]. > > index := 1. > > means at: index put: sum / width. > > width + 1 to: self size do: [ :each | > > sum := sum - (self at: index) + (self at: each). > > index := index + 1. > > means at: index put: sum / width ]. > > ^ means > > > > A good comment, a correct initial bounds check and unit tests are also > > needed. > > > >> I would vote for inclusion in the base image ? > >> With your explanation as comments. > >> > >> I’ll play with it. > >> > >> Thanks > >> Cedrick > >> > >>> Le 12 avr. 2020 à 12:19, Richard O'Keefe <rao...@gmail.com> a écrit : > >>> > >>> > >>> I have coded and benchmarked 8 different running mean algorithms. > >>> In the presence of inexact numbers it is not as accurate as > >>> redoing the sums, but it's pretty close, and it's fast. > >>> If "width" is not an integer or is out of range, an error > >>> will be reported by #new: or #at:[put:]. It's based on Welford's > >>> stable update. > >>> > >>> Of course this approach does NOT work for trimmed or Winsorised > >>> means or for medians or any kind of robust estimate of location. > >>> > >>> SequenceableCollection > >>> methods for: 'summarising' > >>> runningMeans: width > >>> |a m d| > >>> a := Array new: self size - width + 1. > >>> m := 0. > >>> 1 to: width do: [:i | > >>> m := (self at: i) + m]. > >>> m := m / width. > >>> d := 1. > >>> a at: d put: m. > >>> width + 1 to: self size do: [:i | > >>> m := ((self at: i) - (self at: d)) / width + m. > >>> d := d + 1. > >>> a at: d put: m]. > >>> ^a > >>> > >>> > >>> > >>> > >>> > >> > > > > > >
