The Inbox: TraitsTests-pre.19.mcz
Locked
12
12
 
|
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! |
Re: The Inbox: TraitsTests-pre.19.mcz
|
|
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: aSymbol >+ instanceVariableNames: '' >+ classVariableNames: '' >+ poolDictionaries: '' >+ category: self categoryName. >+ self createdClassesAndTraits add: class. >+ ^class! > > |
Re: The Inbox: TraitsTests-pre.19.mcz
|
|
In reply to this post by commits-2
+1 for improving the usability of traits.
--Hannes On 3/28/19, [hidden email] <[hidden email]> 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? > > 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: aSymbol >>+ instanceVariableNames: '' >>+ classVariableNames: '' >>+ poolDictionaries: '' >>+ category: self categoryName. >>+ self createdClassesAndTraits add: class. >>+ ^class! >> >> > > |
Re: The Inbox: TraitsTests-pre.19.mcz
|
|
In reply to this post by commits-2
On Thu, 28 Mar 2019, [hidden email] 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: aSymbol >> + instanceVariableNames: '' >> + classVariableNames: '' >> + poolDictionaries: '' >> + category: self categoryName. >> + self createdClassesAndTraits add: class. >> + ^class! >> >> |
Re: The Inbox: TraitsTests-pre.19.mcz
|
|
> On 2019-03-28, at 10:43 AM, Levente Uzonyi <[hidden email]> wrote: > > On Thu, 28 Mar 2019, [hidden email] 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; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Living proof that nature does not abhor a vacuum. |
Re: The Inbox: TraitsTests-pre.19.mcz
|
|
On 3/28/19, tim Rowledge <[hidden email]> wrote:
> > >> On 2019-03-28, at 10:43 AM, Levente Uzonyi <[hidden email]> wrote: >> >> On Thu, 28 Mar 2019, [hidden email] 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; [hidden email]; http://www.rowledge.org/tim > Useful random insult:- Living proof that nature does not abhor a vacuum. > > > > |
Re: The Inbox: TraitsTests-pre.19.mcz
|
|
> On 2019-03-28, at 1:35 PM, H. Hirzel <[hidden email]> wrote: > > On 3/28/19, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim I'm so skeptical that I'm not sure I'm really a skeptic |
Re: The Inbox: TraitsTests-pre.19.mcz
|
|
In reply to this post by commits-2
Just in case anyone wonders: a workaround is to make the uses list empty #(), this will remove the traits from a class. And if I would not use traits, I wouldn't have known that. I use them to give objects a common protocol based on a few would-be template methods that are "required" by the trait (as described in the paper). I don't like to impose abstract superclasses if there is no common, mandatory state, such as instance variables. Often my trait methods are general defaults that implement the protocol simply, but not efficiently. This allows the user classes to adopt the protocol quickly, based on a few "primitives" (not real primitives, but the template methods). More efficient implementations can replace the trait methods later. But it gets you started. For the same reason I provide traits if I want others to implement that protocol in their objects. At the same time, the traits "document" that protocol, like interfaces in statically typed languages. Abstract superclasses fulfill the same requirements, but seem to dictate inheritance. While you can also just copy their methods, the copies will be out of date when these methods are changed in the abstract superclass. Am Do., 28. März 2019 um 16:22 Uhr schrieb <[hidden email]>: 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. |
Re: The Inbox: TraitsTests-pre.19.mcz
|
|
In reply to this post by Hannes Hirzel
On Thu, 28 Mar 2019, H. Hirzel wrote:
> On 3/28/19, tim Rowledge <[hidden email]> wrote: >> >> >>> On 2019-03-28, at 10:43 AM, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Thu, 28 Mar 2019, [hidden email] 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; [hidden email]; http://www.rowledge.org/tim >> Useful random insult:- Living proof that nature does not abhor a vacuum. >> >> >> >> |
|
|
In reply to this post by timrowledge
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 <[hidden email]> wrote:
|
|
|
In reply to this post by Levente Uzonyi
On Thu, Mar 28, 2019 at 3:25 PM Levente Uzonyi <[hidden email]> wrote: <snip> >>> Just asking, because I'm not aware of any. And if that's the case in 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). |
What are the current use cases for traits? (was: The Inbox: TraitsTests-pre.19.mcz)
|
|
In reply to this post by Levente Uzonyi
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 |
Re: What are the current use cases for traits? (was: The Inbox: TraitsTests-pre.19.mcz)
|
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.package/TViObjectView.trait There are other traits in Vivide to make protocols explicit: https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.package/TViDrawFlags.trait https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.package/TViMemento.trait https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.package/TViObjectNotifier.trait https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.package/TViObjectViewReset.trait https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.package/TViObjectViewSupport.trait https://github.com/hpi-swa/vivide/tree/master-squot/repository/Vivide.package/TViOverlayMessages.trait Best, Marcel
|
Re: What are the current use cases for traits? (was: The Inbox: TraitsTests-pre.19.mcz)
|
|
In reply to this post by David T. Lewis
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 |
Re: What are the current use cases for traits? (was: The Inbox: TraitsTests-pre.19.mcz)
|
|
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.html 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 > |
Re: What are the current use cases for traits? (was: The Inbox: TraitsTests-pre.19.mcz)
|
|
In reply to this post by Levente Uzonyi
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 <[hidden email]> schrieb am So., 31. März 2019, 21:21: On Sat, 30 Mar 2019, David T. Lewis wrote: |
Re: What are the current use cases for traits? (was: The Inbox: TraitsTests-pre.19.mcz)
|
|
In reply to this post by Levente Uzonyi
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 <[hidden email]>: On Sat, 30 Mar 2019, David T. Lewis wrote: |
Re: What are the current use cases for traits? (was: The Inbox: TraitsTests-pre.19.mcz)
|
|
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 <[hidden email]> wrote:
|
Re: What are the current use cases for traits? (was: The Inbox: TraitsTests-pre.19.mcz)
|
|
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 <[hidden email]> wrote:
|
Re: What are the current use cases for traits? (was: The Inbox: TraitsTests-pre.19.mcz)
|
|
In reply to this post by Jakob Reschke
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 <[hidden email]>: > 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 > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |