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

Re: [Pharo-project] About reusing tests via traits
by Bill Schwab Oct. 7, 2008

Oct. 7, 2008

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

3 2

Re: [Pharo-project] About reusing tests via traits
by Bill Schwab Oct. 7, 2008

Oct. 7, 2008

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

4 4

[Pharo-project] One of the most active projects on GForge
by Damien Cassou Oct. 7, 2008

Oct. 7, 2008

Rank: 8 https://gforge.inria.fr/ -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

2 1

Re: [Pharo-project] Re: about ifEmptyOrNil:
by Bill Schwab Oct. 6, 2008

Oct. 6, 2008

Strings, eh??? Now this makes more sense. I have defined some methods named #isNonTrivial that I use in some "defensive" situations (ok, a few are quite simly cowardly<g>), all the way up to decisions about how to represent chunks of medical records. Most senders are of the latter type. Looking at it that way, I'm less bothered by it, but the name is not all that inspiring. However, my biggest gripes about Squeak has been the "you can't do that because I think it's ugly" thinking, so far be it from me to try to insist it go. I suggest nudging it toward #isNonTrivial if you want to keep 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 >>> mike(a)mjr104.co.uk 10/6/2008 4:28 PM >>> I agree with Lukas, and the other comments on the naming that really you imply a test for nil first before the empty. My experience with coming across and recalling heavy usage is that the receiver is always a String. I took it to be a convenience (laziness) for typing the longer form during string processing that is perhaps written in a procedural manner. If the receiver is treated like a collection, i.e. using do: select: etc then an empty collection is a fine null object. Don't mind it being dropped, but perhaps it could remain on String? Is the convenience justified? thanks, Mike On Mon, Oct 6, 2008 at 9:35 PM, nicolas cellier <ncellier(a)ifrance.com> wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > >> >> 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 >> > > > Seriously, why should this message return nil? > Isn't the meaning clear? isEmpty or isNil. > Or do you suggest UndefinedObject should implement #isEmpty and #ifEmpty: ? > > Now what are the advantages over (x isNil or: [x isEmpty])? > - can be used on an arbitrary expression without storing in a temp > - a tiny performance improvement if ever used in a tight loop. > Very limited indeed, and not a good candidate for a tiny kernel. > With this light, I better understand your mood. > > The arguments to not remove it are inertia as usual. > I see 163 senders in the 10074 image and probably many more in Squeak packages. > Le ver est dans le fruit. > > If you want to remove such message, it would be good to have a base of > refactoring rules to be applied on Squeak packages so that they become Pharo > friendly. Sort of one-click compatibility automaton. > > Cheers > > > _______________________________________________ > 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

1 0

Re: [Pharo-project] about ifEmptyOrNil:
by Bill Schwab Oct. 6, 2008

Oct. 6, 2008

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 >

2 1

[Pharo-project] Package browser bugs
by StÃ©phane Ducasse Oct. 6, 2008

Oct. 6, 2008

Hi david 2 bugs: - when I select a class in a hierarchy when I click on package, the package is not selected - the drag and drop on a package does not work with me. Let me know if you need a more precise example Stef

3 5

[Pharo-project] [ANN] Demo with both Truetype + Polymorph
by Marcus Denker Oct. 6, 2008

Oct. 6, 2008

Here is a Demo with TrueType fonts and Polymorph installed (only tested on Mac). https://gforge.inria.fr/frs/download.php/7268/Pharo0.1-PolymorphTT.zip Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

16 41

Re: [Pharo-project] about ifEmptyOrNil:
by Bill Schwab Oct. 6, 2008

Oct. 6, 2008

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

4 4

Re: [Pharo-project] Some clearifications
by Bill Schwab Oct. 6, 2008

Oct. 6, 2008

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? 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. Making that export/import cycle as simple as possible will be a useful step in helping people test the development images. 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. 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: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

2 1

Oct. 5, 2008

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

1 0