On Sat, 4 May 2019, Jakob Reschke wrote:

> I have another one:
> For several test cases I have to suppress the display of progress (otherwise the tests would run much slower). To do that, I override performTest to catch the relevant exceptions/notifications and mute them. I need that in
> multiple test case classes, but I do not want to provide the progress suppressing with an abstract test superclass. So I created a trait that contains this performTest override. Test cases that need the progress muted can mix
> that in by using the trait.

IIRC during tests, the progress bar is intentionally redrawn on each 
change to ensure that when the image freezes, you know which test is 
causing the problem.
If there were a method returning the number of milliseconds between 
updates (which is currently 0 in TestRunner >> #basicRunSuite:do:) or 
just a method returning whether it's okay not to redraw the progress bar 
on each update, then test cases where too frequent redraws cause problems 
could just override that method.

> 
> Why don't I want the abstract superclass? Because I have two more such traits for test cases: one that provides additional assert methods for a certain type of object, and one that provides a method for suppressing change
> notifications so the changes file is not cluttered that much when the tests run. As traits I can mix in and combine these into test case classes when they are required.

That indeed sounds useful.

Since there seem to be quite a few users of Traits out there, I think we 
should investigate whether we should improve the support for the current 
Trait implementation or try to port the new stateful trait implementation 
from Pharo.

Levente

> 
> The latter mentioned trait would benefit from a traits implementation with state, though.
> 
> Am So., 31. März 2019 um 21:21 Uhr schrieb Levente Uzonyi <leves at caesar.elte.hu>:
>       On Sat, 30 Mar 2019, David T. Lewis wrote:
>
>       > Changing the subject line to focus on Levente's question.
>       >
>       > On Thu, Mar 28, 2019 at 06:43:11PM +0100, Levente Uzonyi wrote:
>       >>
>       >> What are the current use cases for traits?
>       >
>       > In order to experiment with Git based repositories, I have loaded the
>       > Tonel package from the github repositories of Jakob Reschke.
>       >
>       >       Installer ensureRecentMetacello.
>       >       (Smalltalk classNamed: #Metacello) new
>       >          repository: 'github://j4yk/tonel:squeak';
>       >          baseline: 'Tonel';
>       >          load.
>       >
>       > This brings in the FS-AnsiStreams package, which uses traits.
>       >
>       > Having traits in Squeak allows me to load this package.
>
>       I haven't tried your snippet and I don't know which version of FS depends
>       on Traits, but the one on SqueakSource definitely does not.
>       Btw, Traits can be flattened, so it's possible to make it loadable into
>       images with no Trait support.
>
>       So far all use cases of Traits in this thread (and its parent) were about
>       interfaces. Squeak doesn't have a concept for that, and Traits are
>       definitely more than just simple interfaces (as long as you don't want to
>       interface state). Perhaps we need interfaces instead of traits.
>
>       Levente
>
>       >
>       > Dave
> 
> 
>