- Pharo-dev - lists.pharo.org

[Pharo-project] about traits tests
by StÃ©phane Ducasse Oct. 7, 2008

Oct. 7, 2008

Hi adrian could you explain the logic behind this code in the traits tests self c6: (self createClassNamed: #C6 superclass: ProtoObject uses: { }). ProtoObject removeSubclass: self c6. self c6 superclass: nil. Especially the ProtoObject tx Stef

2 1

[Pharo-project] about class abtractness
by StÃ©phane Ducasse Oct. 7, 2008

Oct. 7, 2008

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

4 6

[Pharo-project] Re: List Help!
by StÃ©phane Ducasse Oct. 7, 2008

Oct. 7, 2008

we will check! Stef On Oct 7, 2008, at 3:42 AM, Rob Rothwell wrote: > Hello, > > I would like to be able to share my pharo findings with the list, > but seem unable to post to pharo-project(a)lists.gforge.inria.fr. > > Can anyone help? I have registered, received confirmation, and > verified... > > Thanks, > > Rob > > ---------- Forwarded message ---------- > From: <pharo-project-owner(a)lists.gforge.inria.fr> > Date: Wed, Oct 1, 2008 at 6:39 AM > Subject: pharo0.1-10074dev08.09.2.image > To: r.j.rothwell(a)gmail.com > > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > >

1 0

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

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