- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About reusing tests via traits

by StÃ©phane Ducasse

you can achieve the same with copy and paste or code generation. What is nice with traits is that they represent a bloc of coherent behavior that can be parametrized. Load the latest Collection-Tests from the pharo source. This is just the start but this is quite cool. Check TEmptyTest. It is applied to OrderedCollection, Basg, Set, Array, Interval (and could be to others too). Yesterday I got a really nice presentation of Miro by alain plantec and he is also using traits. Stef On Oct 6, 2008, at 3:35 AM, Bill Schwab wrote: > Stef, > > Dumb question: are traits essential to it, or simply a way of > achieving > it? Just curious, as I am still trying to put traits in perspective. > They strike me (so far, right or wrong) as a form of multiple > inheritance, which I have assumed (right or wrong) is often not needed > with clever aggregation/composition of single-inheritance objects. > One > very slick use of multiple inheritance in C++ provides an easy way to > implement COM objects with multiple interfaces - not that I have any > desire to do that, but it is slick for C++. Whether that says > something > about multiple inheritance's strengths or about C++'s weaknesses, I'm > not sure :) > > Pearls of wisdom will be eagerly assimilated. > > Bill > > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 10/05/08 5:37 PM >>> > Hi guys > > I did a fun coding session in the train to brest. I started to code > collection tests > as traits (as damien did for stream) and this is reallllly cool. > > I could write some tests and apply them to > OrderedCollection, Set, Bag, Interval..... > I will publish that and continue. I imagine that the coverage for > Collection is > increase a lot. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by StÃ©phane Ducasse

On Oct 6, 2008, at 3:47 AM, David Pennell wrote: > Stef, > > I would expect to see another implementation of ifEmptyOrNil on > UndefinedObject that returns true. > I've seen it used productively for defensive coding in frameworks, > where you may get nil instead of an empty collection passed to you. Hi david Good suggestion. I learned something. UndefinedObject>>isEmptyOrNil "Answer whether the receiver contains any elements, or is nil. Useful in numerous situations where one wishes the same reaction to an empty collection or to nil" ^ true I still find that somehow ugly. Fixing the cause not the problem. Stef

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by StÃ©phane Ducasse

Yes sorry I was in the train and this is isEmptyOrNil: > I don't have an ifEmptyOrNil: in my image only isEmptyOrNil and that > is specified for Collection and UndefinedObject. > > Did I miss something? No

Oct. 6, 2008

Re: [Pharo-project] Some clearifications

by StÃ©phane Ducasse

On Oct 6, 2008, at 7:22 AM, Norbert Hartl wrote: > On Sun, 2008-10-05 at 23:41 +0200, StÃ©phane Ducasse wrote: >>> >>> Taking all together I think we need to split upstream. As long as >>> there >>> is only one upstream you can't check that _before_ it gets >>> published. >>> And people see a version in the upstream as the next stable thing. >>> So >>> we need a side channel for integration and testing. >> >> This sounds like a good idea. >> Now I do not know if this could work because if we integrate >> B1 B2 B3 B4 >> >> and there is a problem we cannot really cancel B2 just add B5 to >> fix >> it. >> > I think there are cases where you have to redo B2, e.g. if it is not > loadable. Yes but there are case where you have to redo B3 if it depends/is based on B3 > Then just redo it and post it to the list. Everyone using a > development upstream should read the list. > Removing B2 is not necessary because B5 undoes the problem of B2. And > that is exactly the reason for doing an development upstream. You can > undo things before merging the whole thing into the official upstream. > The official one does not contain anything faulty from B2. What might > be a problem is that version numbers on dev are getting larger faster > than on the official one (if you use a single number). > > So the usual development case is that you take the latest official > release S1 and do subsequent D1, D2, D3, D4 enhancements. If you > think everything is stable and worth publishing you merge D4 into S1 > and create S2. Based on that you do D5, D6, D7 and so on. This is already what we do somehow with publishing an image. But we do not have two streams. > > About the naming scheme I'm not sure. I would prefer something like > stable version 1 and development version 1.1, 1.2, 1.3 than stable > version 2 and development 2.1, 2.2. So there is no doubt which > development version belongs to which stable version. > > But I don't know how much work it will be to get it work that way. I do not know. What we can do is to have enough time and testers using the up stream. :) > > > Norbert > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 6, 2008

Re: [Pharo-project] Some clearifications

by StÃ©phane Ducasse

On Oct 6, 2008, at 3:46 AM, Bill Schwab wrote: > Stef, > > Would you not simply fix B2? I could easily be missing something; > perhaps B2 is an external package that works in Squeak but clobbers > Pharo?? > Is it something else? No this is the same in all Smalltalk, if B3 was based on B2. then you have to remove all the streamed elements based on B2. > > > FWIW, I envision a stable release and active development, much as > happens on Squeak, just consistent with the Pharo frame of mind. New > contributions would tend to go into the development release, some that > are of near-term interest could be tested and "back-ported" (aka > installed in the next stable release). Every so often, I would > further > envision doing some type of export of all my stable-version Pharo code > and loading into the development release to look for problems or to > verify that all is well. yes. I think that we can consider that we already have that when we do not publish a new image. We can say that the image is the stable version while the stream elements from the last image are the active part. > Making that export/import cycle as simple as possible will be a useful > step in helping people test the development images. No export. We publish packages > Understanding the > existing tools is one of my next goals. For Dolphin, I wrote a tool > called Migrate that helped to sniff out my packages and overrides and > get them loaded in a new image. I would like to find that there is > something so slick that Migrate is not needed for Pharo. Failing > that, > I will port it over, once I figure out what it should do. > Pharo will change. So you will have to port because even if you press a button that load new components they may change something you rely on. > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 10/05/08 5:41 PM >>> >> >> Taking all together I think we need to split upstream. As long as >> there >> is only one upstream you can't check that _before_ it gets published. >> And people see a version in the upstream as the next stable thing. So >> we need a side channel for integration and testing. > > This sounds like a good idea. > Now I do not know if this could work because if we integrate > B1 B2 B3 B4 > > and there is a problem we cannot really cancel B2 just > add B5 to fix > it. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 6, 2008

Re: [Pharo-project] about class abtractness

by StÃ©phane Ducasse

this is why there is a or in my expression and this is why I still would like to have a way to declare a class as abstract even if it does not have abstract methods. stef On Oct 5, 2008, at 11:34 PM, Alexandre Bergel wrote: > A class is said to be abstract if its not reasonable to instantiate > it. An abstract class may perfectly have no abstract method. > > Cheers, > Alexandre > > > On 5 Oct 2008, at 11:49, StÃ©phane Ducasse wrote: > >> I would really like to have a way to specify that a class is >> abstract. >> For example I would like to be able to write a test as follow >> >> self assert: (Collection allSubclasses reject: [:each >> each isAbstract ]) new isEmpty >> >> now saying that isAbstract is if a class has one method sending >> subclassResponsibility is not >> really good for me. >> >> >> May be we could have something like >> >> isAbstract >> >> ^ self declaredAsAbstract >> or: [ (self whichSelectorsReferToSymbol: >> #subclassResponsibility) isEmpty not] >> >> >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 6, 2008

Re: [Pharo-project] About reusing tests via traits

by Alexandre Bergel

Traits are not essential. However they simplify the design of complex class hierarchies. Various case studies show this. Last time I use traits when coding was to share identical visit* methods in visitors that do not belong to the same class hierarchies (since they evaluate different interpreted languages). Cheers, Alexandre On 6 Oct 2008, at 03:35, Bill Schwab wrote: > Stef, > > Dumb question: are traits essential to it, or simply a way of > achieving > it? Just curious, as I am still trying to put traits in perspective. > They strike me (so far, right or wrong) as a form of multiple > inheritance, which I have assumed (right or wrong) is often not needed > with clever aggregation/composition of single-inheritance objects. > One > very slick use of multiple inheritance in C++ provides an easy way to > implement COM objects with multiple interfaces - not that I have any > desire to do that, but it is slick for C++. Whether that says > something > about multiple inheritance's strengths or about C++'s weaknesses, I'm > not sure :) > > Pearls of wisdom will be eagerly assimilated. > > Bill > > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 10/05/08 5:37 PM >>> > Hi guys > > I did a fun coding session in the train to brest. I started to code > collection tests > as traits (as damien did for stream) and this is reallllly cool. > > I could write some tests and apply them to > OrderedCollection, Set, Bag, Interval..... > I will publish that and continue. I imagine that the coverage for > Collection is > increase a lot. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by Norbert Hartl

Stef, I don't have an ifEmptyOrNil: in my image only isEmptyOrNil and that is specified for Collection and UndefinedObject. Did I miss something? Norbert On Sun, 2008-10-05 at 11:31 +0200, StÃ©phane Ducasse wrote: > Hi > > I would like to have your take on that one: > > isEmpty > "Answer whether the receiver contains any elements." > > ^self size = 0 > > Why do we need ifEmptyOrNil: > > isEmptyOrNil > "Answer whether the receiver contains any elements, or is nil. > Useful in numerous situations where one > wishes the same reaction to an empty collection or to nil" > ^ self isEmpty > > > why can we use isEmpty: or ifEmpty: aBlock > > ifEmpty: aBlock > "Evaluate the block if I'm empty" > ^ self isEmpty ifTrue: aBlock > > Then from an implementation point of view ifEmptyOrNil: is bogus since > it never returns nil (or should not and is also ill-specified). > I checked ANSI and this is really a boolean. > > I'm the mood to deprecate this method. > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2008

Re: [Pharo-project] Some clearifications

by Norbert Hartl

On Sun, 2008-10-05 at 23:41 +0200, StÃ©phane Ducasse wrote: > > > > Taking all together I think we need to split upstream. As long as > > there > > is only one upstream you can't check that _before_ it gets published. > > And people see a version in the upstream as the next stable thing. So > > we need a side channel for integration and testing. > > This sounds like a good idea. > Now I do not know if this could work because if we integrate > B1 B2 B3 B4 > > and there is a problem we cannot really cancel B2 just add B5 to fix > it. > I think there are cases where you have to redo B2, e.g. if it is not loadable. Then just redo it and post it to the list. Everyone using a development upstream should read the list. Removing B2 is not necessary because B5 undoes the problem of B2. And that is exactly the reason for doing an development upstream. You can undo things before merging the whole thing into the official upstream. The official one does not contain anything faulty from B2. What might be a problem is that version numbers on dev are getting larger faster than on the official one (if you use a single number). So the usual development case is that you take the latest official release S1 and do subsequent D1, D2, D3, D4 enhancements. If you think everything is stable and worth publishing you merge D4 into S1 and create S2. Based on that you do D5, D6, D7 and so on. About the naming scheme I'm not sure. I would prefer something like stable version 1 and development version 1.1, 1.2, 1.3 than stable version 2 and development 2.1, 2.2. So there is no doubt which development version belongs to which stable version. But I don't know how much work it will be to get it work that way. Norbert

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by David Pennell

Stef, I would expect to see another implementation of ifEmptyOrNil on UndefinedObject that returns true. I've seen it used productively for defensive coding in frameworks, where you may get nil instead of an empty collection passed to you. -david On Sun, Oct 5, 2008 at 8:28 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Stef, > > I suspect your mood is appropriate. Most likely, it masks a failure to > initialize something to a collection. Unless there is a performance > argument (e.g. many are created, few are actually used, or something > like that??), then it probably should go. > > Bill > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > >>> stephane.ducasse(a)inria.fr 10/05/08 5:31 AM >>> > Hi > > I would like to have your take on that one: > > isEmpty > "Answer whether the receiver contains any elements." > > ^self size = 0 > > Why do we need ifEmptyOrNil: > > isEmptyOrNil > "Answer whether the receiver contains any elements, or > is nil. > Useful in numerous situations where one > wishes the same reaction to an empty collection or to > nil" > ^ self isEmpty > > > why can we use isEmpty: or ifEmpty: aBlock > > ifEmpty: aBlock > "Evaluate the block if I'm empty" > ^ self isEmpty ifTrue: aBlock > > Then from an implementation point of view ifEmptyOrNil: is bogus since > it never returns nil (or should not and is also ill-specified). > I checked ANSI and this is really a boolean. > > I'm the mood to deprecate this method. > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 6, 2008