Okay. I look at several papers about traits, and all the ones I saw need a few time to digest and I am also more or less in a hurry right now. About looking at the code and trying, which canonical examples can you suggest to look at? Hilaire 2009/2/4 Alexandre Bergel <alexandre@bergel.eu>:

I am not aware of such a tutorial. The best is probably to use it. Note that I provided a refactoring "move methods into a new traits" that may help. Just give a try and ask questions :-)

We are planning to write such tutorial, but resources (especially time) are quite scarce these days (which is not necessarily a bad thing by the way)

Alexandre

On 4 Feb 2009, at 17:38, Hilaire Fernandes wrote:

...

Hi,

Can someone suggest me a nice traits tutorial to quickly start with it?

Thanks

Hilaire

-- http://blog.ofset.org/hilaire

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- http://blog.ofset.org/hilaire

I spent 30 seconds on this scenario, so maybe it is a bit flaky, but nevertheless it should convey the idea. Have a look at the classes FileStreamTest, FileDirectoryTest, DosFileDirectoryTests, and MacFileDirectoryTest. Glancing at these classes I can say that: - DosFileDirectoryTests tests many features of fileDirectory. - MacFileDirectoryTest tests very few - FileDirectoryTest has a few tests - FileStreamTest is almost empty I am not expert in files, but I suspect that a common "behavior" must be shared among these 4 classes. For example, file existence, what you write in a file is what you read afterward, ... Assuming that these 4 classes should cover these "behaviors", I would therefore affirm that some test classes are incomplete. Making these 4 classes cover the behavior will probably generate code duplication. And Inheritance may be not that well adapted (again, I haven't though a lot about it). However, with traits the solution will be quite easy: - Create a new trait. For example, TExistingFileTest, that defines a method testExists. You can inspire yourself from FileDirectoryTest - Make this test used by these 4 classes. - The tricky think is to define the right "fixture". A fixture is the code necessary by a test class to test the domain it is related to. Cheers, Alexandre On 4 Feb 2009, at 17:54, Hilaire Fernandes wrote:

Okay. I look at several papers about traits, and all the ones I saw need a few time to digest and I am also more or less in a hurry right now.

About looking at the code and trying, which canonical examples can you suggest to look at?

Hilaire

2009/2/4 Alexandre Bergel <alexandre@bergel.eu>:

...

I am not aware of such a tutorial. The best is probably to use it. Note that I provided a refactoring "move methods into a new traits" that may help. Just give a try and ask questions :-)

We are planning to write such tutorial, but resources (especially time) are quite scarce these days (which is not necessarily a bad thing by the way)

Alexandre

On 4 Feb 2009, at 17:38, Hilaire Fernandes wrote:

...

Hi,

Can someone suggest me a nice traits tutorial to quickly start with it?

Thanks

Hilaire

-- http://blog.ofset.org/hilaire

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- http://blog.ofset.org/hilaire

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Hilaire have a look at CollectionsTest there are really simple example of traits. In 5 minutes you should get that: You have a trait TRemoveTest Trait named: #TRemoveTest uses: {} category: 'CollectionsTests-Abstract' easy TRemoveTest>>testRemoveElementFromEmpty "self debug: #testRemoveElementFromEmpty" self should: [self empty remove: self nonEmpty anyOne] raise: Error Easy self empty is undefined and it will return an empty collection self nonEmpty and nonEmpty one testRemoveElementThatExists "self debug: #testRemoveElementThatExists" | el res | el := self nonEmpty anyOne. self shouldnt: [res := self nonEmpty remove: el ] raise: Error. self assert: res == el testRemoveElementReallyRemovesElement "self debug: #testRemoveElementReallyRemovesElement" | size | size := self nonEmpty size. self nonEmpty remove: self nonEmpty anyOne. self assert: (size -1) = self nonEmpty size OK now you use the trait in a class For example Object subclass: #MySetTest uses: TRemoveTest instanceVariableNames: 'full empty You define setUp full := Set new add: 5 ; add: 6 ;yourself empty := Set new. nonEmpty ^ full empty ^ empty This is it!!!!! You can reuse your traits in another Test. Now if you do not like a trait method you can remove it or redefine it in your class DONE!!! Stef

Thanks for this short how-to Hilaire 2009/2/4 Stéphane Ducasse <stephane.ducasse@inria.fr>:

Hilaire

have a look at CollectionsTest there are really simple example of traits. In 5 minutes you should get that:

You have a trait TRemoveTest

Trait named: #TRemoveTest uses: {} category: 'CollectionsTests-Abstract'

easy

TRemoveTest>>testRemoveElementFromEmpty "self debug: #testRemoveElementFromEmpty"

self should: [self empty remove: self nonEmpty anyOne] raise: Error

Easy self empty is undefined and it will return an empty collection self nonEmpty and nonEmpty one

testRemoveElementThatExists "self debug: #testRemoveElementThatExists"

| el res | el := self nonEmpty anyOne. self shouldnt: [res := self nonEmpty remove: el ] raise: Error. self assert: res == el

testRemoveElementReallyRemovesElement "self debug: #testRemoveElementReallyRemovesElement"

| size | size := self nonEmpty size. self nonEmpty remove: self nonEmpty anyOne. self assert: (size -1) = self nonEmpty size

OK now you use the trait in a class For example

Object subclass: #MySetTest uses: TRemoveTest instanceVariableNames: 'full empty

You define

setUp full := Set new add: 5 ; add: 6 ;yourself empty := Set new.

nonEmpty

^ full

empty ^ empty

This is it!!!!! You can reuse your traits in another Test.

Now if you do not like a trait method you can remove it or redefine it in your class

DONE!!!

Stef

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- http://blog.ofset.org/hilaire