Traits could be used to do functional programming unless i am wrong.

Separate a program into Traits and Objects<—-[ with just accessors ].

So now the Objects become like a database layer or IO layer in functional
programming. Maybe then the Object accessors might be nearer to the place
of the IO Monad in Haskell parlance. So now you put all your working code
into Traits which are pure functions as far as i can tell.

And then you get a kind of functional programming effect.

Now the compiler should have an easier time reasoning about the pure
functional Trait code especially if the imperative style is not used. One
way to go functional is to make all your local variables be BlockClosure
inputs in not persisting Blocks as such input variables are immutable.
Having the compiler optimize these >>value: calls away should be child’s
play to where even i could do it. I believe i have a .pdf that tells how to
do it. Or a new standardized idiom like

o asLocal:[ :v | ... ].
( o1 ,, o2 , o3 )asLocals:[ :v1 :v2 :v3 | ... ]

[ :v1 :v2 :v3 | ... ]value:o1 value:o2 value:o3
could easily be optimized away and give the compiler access to simpler
functional optimizations.

What if some or all of the actual data in these Objects was somewhere else
like in Clojure via FFI or COM or DCOM or sockets or d-Bus or named shared
queues etc. Then you could get immutable.

I have been itching to experiment with this. I made a Class that was like a
Trait once in Pharo before i knew about Traits. If i had known about Traits
i would have made it a Trait instead. It was about editing children and
could be used anywhere there are children. Which is anywhere there is a
mutable SequenceableCollection like thing really. You could also make one
that is for immutable Sequences. So you could easily add this capability to
anything that has children. Which i thought was cool. But then i turned
around and did it the usual Smalltalk way. Leaving the Trait for later.

But i definitely do not want Traits to go away unless i can load them back
in.

On Fri, May 3, 2019 at 16:47 Jakob Reschke <forums.jakob at resfarm.de> 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.
>
> 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.
>
> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190503/0589957a/attachment.html>