> 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
Great. If only categories were more first class, we could store such information. I agree that a proper name is important but this is kind of hell to do bu yourself as minait no help. From you definition, I see that the category can be associated to tests that might eventually auto categorize. Anyway, with such artefact, this is before being a tool artefact, a discipline one (convetions). I just have headaches each time I have to write my categories ^^especially with the UI. Shouldn’t category by more like tags ? And first class object (more source oriented even if some could be helpful at runtime like private methods) ? Cheers, Cédrick > 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> >
