- Pharo-dev - lists.pharo.org

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

by Adrian Lienhard

Thanks, Alex! Adrian On Oct 7, 2008, at 11:21 , Alexandre Bergel wrote: > I changed the title to Pharo Development > > Cheers, > Alexandre > > > On 7 Oct 2008, at 11:06, StÃ©phane Ducasse wrote: > >> sure give one string >> >> Stef >> >> On Oct 6, 2008, at 9:20 PM, Tudor Girba wrote: >> >>> How about "Pharo Development"? >>> >>> Doru >>> >>> >>> On Oct 6, 2008, at 6:09 PM, Lukas Renggli wrote: >>> >>>>> 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 >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> www.tudorgirba.com >>> www.tudorgirba.com/blog >>> >>> "Next time you see your life passing by, say 'hi' and get to know >>> her." >>> >>> >>> >>> _______________________________________________ >>> 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. 7, 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. > > What? > Have a look at Nile and the refactoring of the collection hierarchy > made by nathanael. >> However, this is hard to achieve, and we do not have resource to >> conduct such experiment. > > This is what we are doing with Bloc a new collection library. I meant large scale experiment that include several developers. But this is not important here... 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 >> > > > _______________________________________________ > 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. 7, 2008

Re: [Pharo-project] about traits tests

by Adrian Lienhard

Norbert added this to properly clean up. The reason is that adding a subclass to ProtoObject adds this class to its subclasses array. see http://code.google.com/p/pharo/issues/detail?id=13 Adrian On Oct 6, 2008, at 21:21 , StÃ©phane Ducasse wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 7, 2008

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

by Alexandre Bergel

I changed the title to Pharo Development Cheers, Alexandre On 7 Oct 2008, at 11:06, StÃ©phane Ducasse wrote: > sure give one string > > Stef > > On Oct 6, 2008, at 9:20 PM, Tudor Girba wrote: > >> How about "Pharo Development"? >> >> Doru >> >> >> On Oct 6, 2008, at 6:09 PM, Lukas Renggli wrote: >> >>>> 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 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "Next time you see your life passing by, say 'hi' and get to know >> her." >> >> >> >> _______________________________________________ >> 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. 7, 2008

Re: [Pharo-project] about class abtractness

by StÃ©phane Ducasse

Now what was cool with nathanael browser is that it shows you on the fly that a method was broken: invoking an ill defined selector or abstract methods And normally you should not have an abstract class instantiated so been able to check would make sense. Stef On Oct 6, 2008, at 11:13 PM, Michael Roberts wrote: > I wonder whether if there is a difference between the general case, > and the specific case which Stef suggests writing a test for > Collection subclasses. If the behaviour of each concrete collection > class is not going to change particularly quickly, i.e. the class > hierarchy for Collection is fairly static most of the time, then you > do not necessarily need a clever implementation of isAbstract for that > subset of all classes in the system. You could just mark classes > abstract or not as a method answering true or false. In the general > case for Object>>isAbstract perhaps you need a reflective > implementation. Along these lines, Dictionary is always going to be > concrete, so why not implement isAbstract ^false. In this case I > would prefer practicality over trying to work out if Dictionary, in > this example, breaks some semantics of abstractness. Consider that > someone adds an abstract method to Dictionary, if that method is not > attempted to be invoked, i.e. it is not sent, from the POV of the > client who does not know about the enhanced protocol, it is still > concrete. Even though in a semantic check of abstractness it would > fail. Do you want a test for abstractness to fail in this case? What > is the real desire? > > As for overriding #new, for example taking Singleton pattern > implementations, I find that somewhat problematic in systems where it > is very prevalent. One person's singleton, is not anothers - e.g. > instantiating singletons to unit test them, where implicitly you break > the pattern or have to send basicNew or some circumvention. I find it > too restrictive to override new simply because it was thought at the > time there would only ever be one instance. Now we're talking about > abstractness not singletons, but I wonder if there is not a use for > this in the sense of being a bit more liberal for future use. I can't > think of one right now, perhaps when transitioning classes from > concrete to abstract and vice versa, but there are plenty of > singletons in systems that aren't strictly so- so there is some > precedent for this being too restrictive. > > Mike > > On Mon, Oct 6, 2008 at 9:02 AM, Simon Kirk <simon(a)pinesoft.co.uk> > wrote: >> If the definition of abstraction is that one can't instantiate an >> instance >> of the abstract class (I'm cribbing the definition of it here a bit >> from >> Java/C#/etc where one can't instantiate abstract classes by >> restriction in >> the language) then how about overriding #new on the class side with >> an >> implementation which provides an exception from any send to #new on >> that >> class and implement an #isAbstract that looks for that exception? >> >> That's of course assuming that non-instantiability is a desired >> behaviour >> here. This could well be a bogus assumption on my part. >> >> Cheers, >> Simon >> >> On 6 Oct 2008, at 07:18, StÃ©phane Ducasse wrote: >> >>> 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 >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> ****************************************************************************************************************************************** >> This email is from Pinesoft Limited. Its contents are confidential >> to the >> intended recipient(s) at the email address(es) to which it has been >> addressed. It may not be disclosed to or used by anyone other than >> the >> addressee(s), nor may it be copied in anyway. If received in error, >> please >> contact the sender, then delete it from your system. Although this >> email and >> attachments are believed to be free of virus, or any other defect >> which >> might affect any computer or IT system into which they are received >> and >> opened, it is the responsibility of the recipient to ensure that >> they are >> virus free and no responsibility is accepted by Pinesoft for any >> loss or >> damage arising in any way from receipt or use thereof. >> ******************************************************************************************************************************************* >> >> >> Pinesoft Limited are registered in England, Registered number: >> 2914825. >> Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA >> >> _______________________________________________ >> 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. 7, 2008

[Pharo-project] Re: List Help!

by StÃ©phane Ducasse

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. > >

Oct. 7, 2008

Re: [Pharo-project] about class abtractness

by StÃ©phane Ducasse

I kind of agree :) On Oct 6, 2008, at 11:13 PM, Michael Roberts wrote: > I wonder whether if there is a difference between the general case, > and the specific case which Stef suggests writing a test for > Collection subclasses. If the behaviour of each concrete collection > class is not going to change particularly quickly, i.e. the class > hierarchy for Collection is fairly static most of the time, then you > do not necessarily need a clever implementation of isAbstract for that > subset of all classes in the system. You could just mark classes > abstract or not as a method answering true or false. In the general > case for Object>>isAbstract perhaps you need a reflective > implementation. Along these lines, Dictionary is always going to be > concrete, so why not implement isAbstract ^false. In this case I > would prefer practicality over trying to work out if Dictionary, in > this example, breaks some semantics of abstractness. Consider that > someone adds an abstract method to Dictionary, if that method is not > attempted to be invoked, i.e. it is not sent, from the POV of the > client who does not know about the enhanced protocol, it is still > concrete. Even though in a semantic check of abstractness it would > fail. Do you want a test for abstractness to fail in this case? What > is the real desire? > > As for overriding #new, for example taking Singleton pattern > implementations, I find that somewhat problematic in systems where it > is very prevalent. One person's singleton, is not anothers - e.g. > instantiating singletons to unit test them, where implicitly you break > the pattern or have to send basicNew or some circumvention. I find it > too restrictive to override new simply because it was thought at the > time there would only ever be one instance. Now we're talking about > abstractness not singletons, but I wonder if there is not a use for > this in the sense of being a bit more liberal for future use. I can't > think of one right now, perhaps when transitioning classes from > concrete to abstract and vice versa, but there are plenty of > singletons in systems that aren't strictly so- so there is some > precedent for this being too restrictive. > > Mike > > On Mon, Oct 6, 2008 at 9:02 AM, Simon Kirk <simon(a)pinesoft.co.uk> > wrote: >> If the definition of abstraction is that one can't instantiate an >> instance >> of the abstract class (I'm cribbing the definition of it here a bit >> from >> Java/C#/etc where one can't instantiate abstract classes by >> restriction in >> the language) then how about overriding #new on the class side with >> an >> implementation which provides an exception from any send to #new on >> that >> class and implement an #isAbstract that looks for that exception? >> >> That's of course assuming that non-instantiability is a desired >> behaviour >> here. This could well be a bogus assumption on my part. >> >> Cheers, >> Simon >> >> On 6 Oct 2008, at 07:18, StÃ©phane Ducasse wrote: >> >>> 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 >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> ****************************************************************************************************************************************** >> This email is from Pinesoft Limited. Its contents are confidential >> to the >> intended recipient(s) at the email address(es) to which it has been >> addressed. It may not be disclosed to or used by anyone other than >> the >> addressee(s), nor may it be copied in anyway. If received in error, >> please >> contact the sender, then delete it from your system. Although this >> email and >> attachments are believed to be free of virus, or any other defect >> which >> might affect any computer or IT system into which they are received >> and >> opened, it is the responsibility of the recipient to ensure that >> they are >> virus free and no responsibility is accepted by Pinesoft for any >> loss or >> damage arising in any way from receipt or use thereof. >> ******************************************************************************************************************************************* >> >> >> Pinesoft Limited are registered in England, Registered number: >> 2914825. >> Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA >> >> _______________________________________________ >> 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. 7, 2008

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

by StÃ©phane Ducasse

sure give one string Stef On Oct 6, 2008, at 9:20 PM, Tudor Girba wrote: > How about "Pharo Development"? > > Doru > > > On Oct 6, 2008, at 6:09 PM, Lukas Renggli wrote: > >>> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Next time you see your life passing by, say 'hi' and get to know > her." > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 7, 2008

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

by StÃ©phane Ducasse

On Oct 6, 2008, at 5:45 PM, 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. what damien proved is that having accessor does not slow down and that more important that you can optimize too and reuse with 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 7, 2008

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

by StÃ©phane Ducasse

On Oct 6, 2008, at 5:19 PM, Alexandre Bergel wrote: > I agree with your Bill. No strong empirical study have been made > that demonstrate the benefit of traits over traditional class > inheritance. What? Have a look at Nile and the refactoring of the collection hierarchy made by nathanael. > However, this is hard to achieve, and we do not have resource to > conduct such experiment. This is what we are doing with Bloc a new collection library. > 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. 7, 2008