October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Changing the name of the Pharo mailing list

by Lukas Renggli

> It currently is "An open mailing list to discuss any topics related to an > open-source Smalltalk" > I would prefer "The genera-purpose Pharo developer list" or something > similar that is shorter and includes Pharo. +1 I currently only see "An open mailing ..." I guess with Adrian's suggestion I only see "The general-purpose ..." I suggest something that starts with Pharo: "Pharo Developer List" Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 6, 2008

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

by Adrian Lienhard

Bill, On Oct 6, 2008, at 17:45 , Bill Schwab wrote: > Alexandre, > > Any performance hit aside, I am willing to go along. However, the > direction of the crowd generally makes me suspicious vs. reassuring me > that something is correct. Granted, this isn't the Visual > this-that-or-the-other-thing.CloudyNET marketing group telling us what > they think we should do. > > Re performance, IIRC, Damien found Nile does well vs. Squeak's > streams. > It would be interesting to know how much of that is good design vs. > traits. Traits as implemented in Squeak/Pharo have no execution overhead. Everything happens at compile time. Adrian ___________________ http://www.adrian-lienhard.ch/

Oct. 6, 2008

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

by Bill Schwab

Alexandre, Any performance hit aside, I am willing to go along. However, the direction of the crowd generally makes me suspicious vs. reassuring me that something is correct. Granted, this isn't the Visual this-that-or-the-other-thing.CloudyNET marketing group telling us what they think we should do. Re performance, IIRC, Damien found Nile does well vs. Squeak's streams. It would be interesting to know how much of that is good design vs. traits. 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 >>> alexandre(a)bergel.eu 10/06/08 11:19 AM >>> I agree with your Bill. No strong empirical study have been made that demonstrate the benefit of traits over traditional class inheritance. However, this is hard to achieve, and we do not have resource to conduct such experiment. We are therefore left to our intuition that using traits is better than not using them. But a large crowd (and not only in the research community) has the same intuition. Cheers, Alexandre On 6 Oct 2008, at 16:07, Bill Schwab wrote: > Stef, Alexandre, > > I will grant you a head start: if you have to copy code, it's not the > same thing. My next question would be whether a competitive "say it > once" design could be realized with composition and single > inheritance. > Alexandre refers to use cases the show an advantage, and I do not > dispute that. I am mostly just curious at this point. Is there > more or > less overhead specifying the traits vs. arranging for good > composition? > My guess would be that the traits win, but I have no data to support > that. Is there a performance advantage either way? > > Unless traits are (whether used or not) very expensive at runtime, I > would argue that anything that gets us better test coverage is a good > thing. > > 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/06/08 2:32 AM >>> > 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 >> > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ 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] Changing the name of the Pharo mailing list

by Serge Stinckwich

2008/10/6 Adrian Lienhard <adi(a)netstyle.ch>: > Stef, > > Is it possible to change the long name of the mailing list that is used for > pharo-project(a)lists.gforge.inria.fr? > It currently is "An open mailing list to discuss any topics related to an > open-source Smalltalk" > I would prefer "The genera-purpose Pharo developer list" or something > similar that is shorter and includes Pharo. +1 -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

Oct. 6, 2008

[Pharo-project] Changing the name of the Pharo mailing list

by Adrian Lienhard

Stef, Is it possible to change the long name of the mailing list that is used for pharo-project(a)lists.gforge.inria.fr? It currently is "An open mailing list to discuss any topics related to an open-source Smalltalk" I would prefer "The genera-purpose Pharo developer list" or something similar that is shorter and includes Pharo. Its just a detail, but it would be worth to change if it does not take much time... Adrian ___________________ http://www.adrian-lienhard.ch/

Oct. 6, 2008

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

by Alexandre Bergel

I agree with your Bill. No strong empirical study have been made that demonstrate the benefit of traits over traditional class inheritance. However, this is hard to achieve, and we do not have resource to conduct such experiment. We are therefore left to our intuition that using traits is better than not using them. But a large crowd (and not only in the research community) has the same intuition. Cheers, Alexandre On 6 Oct 2008, at 16:07, Bill Schwab wrote: > Stef, Alexandre, > > I will grant you a head start: if you have to copy code, it's not the > same thing. My next question would be whether a competitive "say it > once" design could be realized with composition and single > inheritance. > Alexandre refers to use cases the show an advantage, and I do not > dispute that. I am mostly just curious at this point. Is there > more or > less overhead specifying the traits vs. arranging for good > composition? > My guess would be that the traits win, but I have no data to support > that. Is there a performance advantage either way? > > Unless traits are (whether used or not) very expensive at runtime, I > would argue that anything that gets us better test coverage is a good > thing. > > 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/06/08 2:32 AM >>> > 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 >> > > > _______________________________________________ > 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 reusing tests via traits

by Lukas Renggli

> 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). I wonder what the advantages of using Traits over creating a test class hierarchy mirroring the collection hierarchy is? Normally the tests in TEmptyTests should be valid on all collections and should thus be run automatically on all subclasses of Collection. If you would put these test methods in CollectionTest you would have the same result, ensuring that all subclasses satisfy the contracts of Collection. I think it is too easy to forget to add TEmptyTests to a new test (especially if there are many such traits). And if somebody intentionally avoids adding TEmptyTests, then he probably shouldn't have subclassed Collection at all. I successfully use test hierarchies in Magritte and Pier from the very beginning. This allows me to specify exact contracts in the (abstract) superclasses that are then automatically checked on all its subclasses. OB-RB has functionality to ensure that both class hierarchies are identical. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 6, 2008

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

by Bill Schwab

Stef, Alexandre, I will grant you a head start: if you have to copy code, it's not the same thing. My next question would be whether a competitive "say it once" design could be realized with composition and single inheritance. Alexandre refers to use cases the show an advantage, and I do not dispute that. I am mostly just curious at this point. Is there more or less overhead specifying the traits vs. arranging for good composition? My guess would be that the traits win, but I have no data to support that. Is there a performance advantage either way? Unless traits are (whether used or not) very expensive at runtime, I would argue that anything that gets us better test coverage is a good thing. 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/06/08 2:32 AM >>> 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 > _______________________________________________ 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 David Pennell

I think it's reasonable to ditch it. Its just syntactic sugar (and should have probably been named ifNilOrEmpty). -david On Mon, Oct 6, 2008 at 6:28 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > David, > > I first heard of defensive programming in the spirit of getting around > the dreaded UAE of the pre-exceptions world of Windows. My sense was > that it didn't stick for a few reasons: (1) 32 bit address spaces > greatly reduced the need for creative memory management, all but > eliminating a gratuitous source of human error ; (2) even more > important, the arrival of structured exception handling along with the > 32 bit pointers; (3) in many situations, defensive programmer (as I > understand it) is a formalization for creating programs that suppress > their problems vs. dealing with them. I tried it with numerical > analysis code in that same era, and very quickly discovered that it was > better to have a crash than garbage results. > > There are of course times when a crash is intolerable, and I especially > do not think we should dictate our ideas of aesthetics (one of my main > gripes about Squeak). I am inclined to vote against this one, but it > there is interest in keeping it, I suppose it is better to code it once > correctly than to force people to inline it and maybe botch it. > However, I can also argue that #isNil and #isEmpty both exist, and > > ( x isNil or:[ x isEmpty ] ) ifTrue:[ > "run for the hills" > ]. > > is not ambiguous. In most situations, an empty collection is not a > threat - iterating it seldom hurts. Like I said, I'm inclined to vote > this one down, but won't start a battle over it. > > 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 > > >>> pennell.david(a)gmail.com 10/05/08 9:47 PM >>> > 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 > > > > > _______________________________________________ > 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 Bill Schwab

David, I first heard of defensive programming in the spirit of getting around the dreaded UAE of the pre-exceptions world of Windows. My sense was that it didn't stick for a few reasons: (1) 32 bit address spaces greatly reduced the need for creative memory management, all but eliminating a gratuitous source of human error ; (2) even more important, the arrival of structured exception handling along with the 32 bit pointers; (3) in many situations, defensive programmer (as I understand it) is a formalization for creating programs that suppress their problems vs. dealing with them. I tried it with numerical analysis code in that same era, and very quickly discovered that it was better to have a crash than garbage results. There are of course times when a crash is intolerable, and I especially do not think we should dictate our ideas of aesthetics (one of my main gripes about Squeak). I am inclined to vote against this one, but it there is interest in keeping it, I suppose it is better to code it once correctly than to force people to inline it and maybe botch it. However, I can also argue that #isNil and #isEmpty both exist, and ( x isNil or:[ x isEmpty ] ) ifTrue:[ "run for the hills" ]. is not ambiguous. In most situations, an empty collection is not a threat - iterating it seldom hurts. Like I said, I'm inclined to vote this one down, but won't start a battle over it. 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 >>> pennell.david(a)gmail.com 10/05/08 9:47 PM >>> 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