Patrick Rein uploaded a new version of TraitsTests to project The Inbox: http://source.squeak.org/inbox/TraitsTests-pre.19.mcz
==================== Summary ====================
Name: TraitsTests-pre.19 Author: pre Time: 28 March 2019, 3:30:48.769796 pm UUID: 2ed07595-23e5-5f41-92ef-17c27ad0a017 Ancestors: TraitsTests-ul.18
Adds a test case for removing traits from a class by simply executing a class creation method without a trait composition. This does currently not yet work.
=============== Diff against TraitsTests-ul.18 ===============
Item was added: + ----- Method: TraitTest>>expectedFailures (in category 'failures') ----- + expectedFailures + + ^ #(testRemoveTraitBySimpleClassDefinition)!
Item was added: + ----- Method: TraitTest>>testRemoveTraitBySimpleClassDefinition (in category 'testing') ----- + testRemoveTraitBySimpleClassDefinition + + | classAv1 classAv2 | + classAv1 := self createClassNamed: #TraitTestMethodClassA superclass: Object uses: T1. + classAv2 := self createClassNamed: #TraitTestMethodClassA superclass: Object. + + self assert: classAv1 == classAv2. + self assert: classAv2 traits isEmpty.!
Item was added: + ----- Method: TraitsTestCase>>createClassNamed:superclass: (in category 'utility') ----- + createClassNamed: aSymbol superclass: aClass + | class | + class := aClass + subclass: aSymbol + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: self categoryName. + self createdClassesAndTraits add: class. + ^class!
The test documents the (currently not working) workflow for removing a trait from a class by simply removing the "uses:" line from the class definition. To make this work, we would have to make the Class>>#subclass:instanceVariableNames:classVariableNames:poolDictionaries:category: method aware of traits. The method would have to reset the trait composition as Class>>#subclass:uses:instanceVariableNames:classVariableNames:poolDictionaries:category: currently does. Potentially, the change could also be embedded deeper in the class creation code to avoid that duplication and make the other class creation methods more robust.
I am hesitant, as I am aware that traits have been prevented from being integrated more deeply so far. At the same time, the described missing workflow has already led users to struggle with using traits in the first place. So as they are part of the system I would rather improve their usability. Any other oppinions?
Bests Patrick
Patrick Rein uploaded a new version of TraitsTests to project The Inbox: http://source.squeak.org/inbox/TraitsTests-pre.19.mcz
==================== Summary ====================
Name: TraitsTests-pre.19 Author: pre Time: 28 March 2019, 3:30:48.769796 pm UUID: 2ed07595-23e5-5f41-92ef-17c27ad0a017 Ancestors: TraitsTests-ul.18
Adds a test case for removing traits from a class by simply executing a class creation method without a trait composition. This does currently not yet work.
=============== Diff against TraitsTests-ul.18 ===============
Item was added:
- ----- Method: TraitTest>>expectedFailures (in category 'failures') -----
- expectedFailures
- ^ #(testRemoveTraitBySimpleClassDefinition)!
Item was added:
- ----- Method: TraitTest>>testRemoveTraitBySimpleClassDefinition (in category 'testing') -----
- testRemoveTraitBySimpleClassDefinition
- | classAv1 classAv2 |
- classAv1 := self createClassNamed: #TraitTestMethodClassA superclass: Object uses: T1.
- classAv2 := self createClassNamed: #TraitTestMethodClassA superclass: Object.
- self assert: classAv1 == classAv2.
- self assert: classAv2 traits isEmpty.!
Item was added:
- ----- Method: TraitsTestCase>>createClassNamed:superclass: (in category 'utility') -----
- createClassNamed: aSymbol superclass: aClass
- | class |
- class := aClass
subclass: aSymbolinstanceVariableNames: ''classVariableNames: ''poolDictionaries: ''category: self categoryName.- self createdClassesAndTraits add: class.
- ^class!
On Thu, 28 Mar 2019, patrick.rein@hpi.uni-potsdam.de wrote:
The test documents the (currently not working) workflow for removing a trait from a class by simply removing the "uses:" line from the class definition. To make this work, we would have to make the Class>>#subclass:instanceVariableNames:classVariableNames:poolDictionaries:category: method aware of traits. The method would have to reset the trait composition as Class>>#subclass:uses:instanceVariableNames:classVariableNames:poolDictionaries:category: currently does. Potentially, the change could also be embedded deeper in the class creation code to avoid that duplication and make the other class creation methods more robust.
I am hesitant, as I am aware that traits have been prevented from being integrated more deeply so far. At the same time, the described missing workflow has already led users to struggle with using traits in the first place. So as they are part of the system I would rather improve their usability. Any other oppinions?
What are the current use cases for traits? Just asking, because I'm not aware of any. And if that's the case in general, then we should remove them. Tool support is still incomplete after 10+ years. And the creators (of Traits in general) have moved on 10+ years ago as well (and have abandoned Traits in this form).
Levente
Bests Patrick
Patrick Rein uploaded a new version of TraitsTests to project The Inbox: http://source.squeak.org/inbox/TraitsTests-pre.19.mcz
==================== Summary ====================
Name: TraitsTests-pre.19 Author: pre Time: 28 March 2019, 3:30:48.769796 pm UUID: 2ed07595-23e5-5f41-92ef-17c27ad0a017 Ancestors: TraitsTests-ul.18
Adds a test case for removing traits from a class by simply executing a class creation method without a trait composition. This does currently not yet work.
=============== Diff against TraitsTests-ul.18 ===============
Item was added:
- ----- Method: TraitTest>>expectedFailures (in category 'failures') -----
- expectedFailures
- ^ #(testRemoveTraitBySimpleClassDefinition)!
Item was added:
- ----- Method: TraitTest>>testRemoveTraitBySimpleClassDefinition (in category 'testing') -----
- testRemoveTraitBySimpleClassDefinition
- | classAv1 classAv2 |
- classAv1 := self createClassNamed: #TraitTestMethodClassA superclass: Object uses: T1.
- classAv2 := self createClassNamed: #TraitTestMethodClassA superclass: Object.
- self assert: classAv1 == classAv2.
- self assert: classAv2 traits isEmpty.!
Item was added:
- ----- Method: TraitsTestCase>>createClassNamed:superclass: (in category 'utility') -----
- createClassNamed: aSymbol superclass: aClass
- | class |
- class := aClass
subclass: aSymbolinstanceVariableNames: ''classVariableNames: ''poolDictionaries: ''category: self categoryName.- self createdClassesAndTraits add: class.
- ^class!
On 2019-03-28, at 10:43 AM, Levente Uzonyi leves@caesar.elte.hu wrote:
On Thu, 28 Mar 2019, patrick.rein@hpi.uni-potsdam.de wrote:
The test documents the (currently not working) workflow for removing a trait from a class by simply removing the "uses:" line from the class definition. To make this work, we would have to make the Class>>#subclass:instanceVariableNames:classVariableNames:poolDictionaries:category: method aware of traits. The method would have to reset the trait composition as Class>>#subclass:uses:instanceVariableNames:classVariableNames:poolDictionaries:category: currently does. Potentially, the change could also be embedded deeper in the class creation code to avoid that duplication and make the other class creation methods more robust. I am hesitant, as I am aware that traits have been prevented from being integrated more deeply so far. At the same time, the described missing workflow has already led users to struggle with using traits in the first place. So as they are part of the system I would rather improve their usability. Any other oppinions?
What are the current use cases for traits? Just asking, because I'm not aware of any. And if that's the case in general, then we should remove them. Tool support is still incomplete after 10+ years. And the creators (of Traits in general) have moved on 10+ years ago as well (and have abandoned Traits in this form).
That's almost exactly what i've been saying for years now; they were (are) an interesting idea but never got properly supported in any tools and so never got to be used in any meaningful way (that I've ever heard of - I'd love to find I'm wrong) but they do 'cost' us a non-zero amount of work to maintain and keep in the system. Kinda like Environments; sounds like a really good idea, we have a load of stuff in the image that has something to do with them but nothing that makes any easily apparent case for using them. And in my current day-job with VW I am coming to deeply, deeply, despise the implementation therein.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Living proof that nature does not abhor a vacuum.
On 3/28/19, tim Rowledge tim@rowledge.org wrote:
On 2019-03-28, at 10:43 AM, Levente Uzonyi leves@caesar.elte.hu wrote:
On Thu, 28 Mar 2019, patrick.rein@hpi.uni-potsdam.de wrote:
The test documents the (currently not working) workflow for removing a trait from a class by simply removing the "uses:" line from the class definition. To make this work, we would have to make the Class>>#subclass:instanceVariableNames:classVariableNames:poolDictionaries:category: method aware of traits. The method would have to reset the trait composition as Class>>#subclass:uses:instanceVariableNames:classVariableNames:poolDictionaries:category: currently does. Potentially, the change could also be embedded deeper in the class creation code to avoid that duplication and make the other class creation methods more robust. I am hesitant, as I am aware that traits have been prevented from being integrated more deeply so far. At the same time, the described missing workflow has already led users to struggle with using traits in the first place. So as they are part of the system I would rather improve their usability. Any other oppinions?
What are the current use cases for traits?
To implement object roles, for example.
Just asking, because I'm not aware of any. And if that's the case in general, then we should remove them. Tool support is still incomplete after 10+ years.
Traits are not used because they are not properly supported,
And the creators (of
Traits in general) have moved on 10+ years ago as well (and have abandoned Traits in this form).
Other issues are also still open after 10 years.
That's almost exactly what i've been saying for years now; they were (are) an interesting idea but never got properly supported in any tools and so never got to be used in any meaningful way (that I've ever heard of - I'd love to find I'm wrong) but they do 'cost' us a non-zero amount of work to maintain and keep in the system.
Patrick stepped forward to do it.
Kinda like Environments; sounds like a really good idea, we have a load of stuff in the image that has something to do with them but nothing that makes any easily apparent case for using them. And in my current day-job with VW I am coming to deeply, deeply, despise the implementation therein.
We are talking about Squeak here. And the environments implementation is a different issue. The work done so far is useful.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Living proof that nature does not abhor a vacuum.
On 2019-03-28, at 1:35 PM, H. Hirzel hannes.hirzel@gmail.com wrote:
On 3/28/19, tim Rowledge tim@rowledge.org wrote:
[snip]
What are the current use cases for traits?
To implement object roles, for example.
Just asking, because I'm not aware of any. And if that's the case in general, then we should remove them. Tool support is still incomplete after 10+ years.
Traits are not used because they are not properly supported,
Exactly; they don't get used because no good support, which means very low odds of there being any interesting uses found for them, which means no tools get developed and round we go. We should never have put them into the image without tools (at least in principle) being developed.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I'm so skeptical that I'm not sure I'm really a skeptic
Hi.
Similar to Jakob, I have used traits in the past. And I plan to use them again shortly.
In both cases, I have used them in conjunction with PetitParser for AST modelling - there are certain commonalities across the classes that don't necessarily conform to abstract/subclass hierarchies that have made them useful in the past (for my COBOL parser) and may also apply in the near future for my DB2 SQL parser. At least for the later, I'd prefer to implement what is needed in Traits instead of forcing the abstract superclass for the AST model.
And this time around I've been ruminating about adding the support needed to make this more useful for work as well. If there are other folks interested (sounds like Patrick and Jakob might be), then all the better.
cbc
On Thu, Mar 28, 2019 at 2:11 PM tim Rowledge tim@rowledge.org wrote:
On 2019-03-28, at 1:35 PM, H. Hirzel hannes.hirzel@gmail.com wrote:
On 3/28/19, tim Rowledge tim@rowledge.org wrote:
[snip]
What are the current use cases for traits?
To implement object roles, for example.
Just asking, because I'm not aware of any. And if that's the case in general, then we should remove them. Tool support is still incomplete after 10+ years.
Traits are not used because they are not properly supported,
Exactly; they don't get used because no good support, which means very low odds of there being any interesting uses found for them, which means no tools get developed and round we go. We should never have put them into the image without tools (at least in principle) being developed.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I'm so skeptical that I'm not sure I'm really a skeptic
On Thu, 28 Mar 2019, H. Hirzel wrote:
On 3/28/19, tim Rowledge tim@rowledge.org wrote:
On 2019-03-28, at 10:43 AM, Levente Uzonyi leves@caesar.elte.hu wrote:
On Thu, 28 Mar 2019, patrick.rein@hpi.uni-potsdam.de wrote:
The test documents the (currently not working) workflow for removing a trait from a class by simply removing the "uses:" line from the class definition. To make this work, we would have to make the Class>>#subclass:instanceVariableNames:classVariableNames:poolDictionaries:category: method aware of traits. The method would have to reset the trait composition as Class>>#subclass:uses:instanceVariableNames:classVariableNames:poolDictionaries:category: currently does. Potentially, the change could also be embedded deeper in the class creation code to avoid that duplication and make the other class creation methods more robust. I am hesitant, as I am aware that traits have been prevented from being integrated more deeply so far. At the same time, the described missing workflow has already led users to struggle with using traits in the first place. So as they are part of the system I would rather improve their usability. Any other oppinions?
What are the current use cases for traits?
To implement object roles, for example.
I meant Traits being used in practice. Why am I asking this? 1. I always considered the idea of stateless Traits too weak to be useful. I proposed class mixing instead about 10 years ago, which IMO could be simpler and cleaner, because there would be no need to introduce a new kind of Behavior. But implementing that would be lots of work. 2. I've never seen them being used for anything that justified their existence.
Just asking, because I'm not aware of any. And if that's the case in general, then we should remove them. Tool support is still incomplete after 10+ years.
Traits are not used because they are not properly supported,
That's what people used to say, but that's not true. Even in Pharo, where Traits were fully supported (with the same capabilities we have now in Squeak), they were only used because of the heavy push from the dictators. Once they found out the shortcomings of the idea of stateless traits, they replaced the implementation altogether with TraitsV2 - aka stateful traits.
And the creators (of
Traits in general) have moved on 10+ years ago as well (and have abandoned Traits in this form).
Other issues are also still open after 10 years.
That shouldn't affect the current discussion about Traits, should it?
That's almost exactly what i've been saying for years now; they were (are) an interesting idea but never got properly supported in any tools and so never got to be used in any meaningful way (that I've ever heard of - I'd love to find I'm wrong) but they do 'cost' us a non-zero amount of work to maintain and keep in the system.
Patrick stepped forward to do it.
Did he? I must have missed it.
Kinda like Environments; sounds like a really good idea, we have a load of stuff in the image that has something to do with them but nothing that makes any easily apparent case for using them. And in my current day-job with VW I am coming to deeply, deeply, despise the implementation therein.
We are talking about Squeak here. And the environments implementation is a different issue. The work done so far is useful.
It's not. Even some of the most basic things are incomplete. It only works because there's only one environment at a time. Moving forward would require system-wide changes.
Levente
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Living proof that nature does not abhor a vacuum.
On Thu, Mar 28, 2019 at 3:25 PM Levente Uzonyi leves@caesar.elte.hu wrote: <snip>
Just asking, because I'm not aware of any. And if that's the case in general, then we should remove them. Tool support is still incomplete after 10+ years.
Traits are not used because they are not properly supported,
That's what people used to say, but that's not true. Even in Pharo, where Traits were fully supported (with the same capabilities we have now in Squeak), they were only used because of the heavy push from the dictators. Once they found out the shortcomings of the idea of stateless traits, they replaced the implementation altogether with TraitsV2 - aka stateful traits.
Stateful traits would indeed be much nicer.
If I remember correctly, there was talk that the existing model could be expanded to handle stateful traits - it was just never done (or at least, never shared).
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.
Dave
Hi, there.
I use traits to describe the expected view interface in Vivide (github.com/hpi-swa/vivide): https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.packag...
There are other traits in Vivide to make protocols explicit: https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.packag... https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.packag... https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.packag... https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.packag... https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.packag... https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.packag...
Best, Marcel Am 31.03.2019 04:54:26 schrieb David T. Lewis lewis@mail.msen.com: 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.
Dave
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
On Sun, Mar 31, 2019 at 09:20:47PM +0200, Levente Uzonyi wrote:
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.
My use case came about because I was reading the "Squeak on Tonel" thread last month:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-February/201567....
Following advice in that thread, I loaded the package according to the instructions here:
https://github.com/j4yk/tonel/blob/squeak/README.md
It worked :-)
I am not advocating for traits, just giving a use case for which the support for traits in Squeak was helpful for me.
Dave
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
I'm the one to blame for adding traits in the FS-AnsiStreams package. At least in my "fork" for Squot and now Tonel that resides on GitHub. I tried to have the readable stream, positionable stream, and writable stream protocols like in the ANSI standard and experimented with that. Might not be the most efficient way, but it works and avoids some the duplication from the traditional Stream class hierarchy.
In Pharo they abandoned the "new" ansi streams and integrated StandardFileStream & co. in FS instead.
Levente Uzonyi leves@caesar.elte.hu schrieb am So., 31. März 2019, 21:21:
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
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@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
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@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@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
A functional way to do local recursion or tail recursion is
[ :recurse | recurse value:o1 value:o2 value:recurse ] value:[ :v1 :v2 :recurse |...( recurse value:o3 value:o4 value:recurse )...]
Also Object>>recurse: allows you to do recursion on anObject as easy as
do: etc do iteration
( anObject recurse:[ :anObject1 :recurse | ...( anObject1 children do:[ :child | …( recurse value:child )… ] ] )
I can show Object>>recurse: it’s really short if anyone is interested
On Fri, May 3, 2019 at 19:31 Kjell Godo squeaklist@gmail.com wrote:
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@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@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
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@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
Levente Uzonyi leves@caesar.elte.hu schrieb am Sa., 4. Mai 2019, 11:12:
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.
Clarification: the code under test produces progress bars and messages and these shall be muted. It also reduces the time spent on Travis CI. Thanks for the hint though!
squeak-dev@lists.squeakfoundation.org
-
Chris Cunningham -
commits＠source.squeak.org -
David T. Lewis -
H. Hirzel -
Jakob Reschke -
Kjell Godo -
Levente Uzonyi -
Marcel Taeumel -
patrick.rein＠hpi.uni-potsdam.de -
tim Rowledge