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

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

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

by StÃ©phane Ducasse

> I wonder what the advantages of using Traits over creating a test > class hierarchy mirroring the collection hierarchy is? When you change a test you have to go to all your hierarchy. Traits do that for you for free. > Normally the tests in TEmptyTests should be valid on all collections > and should thus be run automatically on all subclasses of Collection. Yes this is a bad example, have a look at TIterateTest > > 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. Pluggability. I write one test that I can reuse in most of the tests. > 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 > > _______________________________________________ > 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] About trait mop

by StÃ©phane Ducasse

Hi I have been working on a new API to access class, traits, selector for traits I wrote some tests in the PharoTaskForces/Traits-MOPTests package Now in essence we have - The selector of a compiled method should be its name. An aliased method should have the name of its alias name. - The class of a compiled method is the class that contains it. A compiled method cannot be shared. - The origin of a compiledMethod is its defining class or trait. - The reachHome of a compiled method is class or traits that you changed (and not override) when you want to change a method in the flat view. T1 c c1 T2 c c3 uses: T1 Class A foo uses: T2 testSelectorT11T2 "self debug: #testSelectorT11T2" "The selector of a compiled method should be its name. An aliased method should have the name of its alias name." self assert: (AUsingTrait2>>#foo) selector = #foo. self assert: (Trait1>>#c) selector = #c. self assert: (Trait2>>#c) selector = #c. self assert: (AUsingTrait2>>#c) selector = #c. self assert: (AUsingTrait2>>#c3) selector = #c2. self assert: (BUsingTrait1>>#c) selector = #c. testClassT11T2 "The class of a compiled method is the class that contains it. A compiled method cannot be shared." self assert: (AUsingTrait2>>#foo) methodClass = AUsingTrait2. self assert: (AUsingTrait2>>#c) methodClass = AUsingTrait2. self assert: (AUsingTrait1>>#c3) methodClass = AUsingTrait2. self assert: (AUsingTrait2>>#c1) methodClass = AUsingTrait2. self assert: (BUsingTrait1>>#c) methodClass = BUsingTrait1. self should: (Trait1>>#c1) methodClass = nil. "T1 or nil" self should: (Trait2>>#c2) methodClass = nil. "T2 or nil" self should: (Trait2>>#c1) methodClass = nil. "T2 or nil or T1" testReachHome "self debug: #testReachHome" " The reachHome is the method that you changed (and not override) when you want to change a method in the flat view." self assert: (AUsingTrait2>>#foo) reachHome = AUsingTrait2. self assert: (AUsingTrait2>>#c3) reachHome = Trait2. self assert: (AUsingTrait2>>#c1) reachHome = Trait1. self assert: (AUsingTrait2>>#c) reachHome = Trait2. self assert: (Trait11>>#c) reachHome = Trait11. self assert: (Trait2>>#c) reachHome = Trait2. self assert: (Trait2>>#c1) reachHome = Trait11. self assert: (AUsingTrait1>>#c2) reachHome = AUsingTrait1. testOrigin "self debug: #testClass" "The origin of a compiledMethod is its defining class or trait." self assert: (AUsingTrait2>>#foo) origin = AUsingTrait2. self assert: (AUsingTrait2>>#c3) origin = Trait2. self assert: (AUsingTrait2>>#c1) origin = Trait11. self assert: (AUsingTrait2>>#c) origin = Trait11. self assert: (BUsingTrait1>>#c) origin = Trait1. self assert: (Trait2>>#c3) origin = Trait2. self assert: (Trait11>>#c1) origin = Trait11. self assert: (Trait2>>#c1) origin = Trait11. "since it introduced the alias it is its origin" self assert: (AUsingTrait1>>#c2) origin = AUsingTrait1. testTraitT11T2 "it seems to me that we do not need trait: but we need origin and reachHome" "(A>>foo) trait -> nil (A>>c3) trait -> T2 (A>>c) trait -> T2 (A>>c1) trait -> T2 ***** since it is flat (T1>>c1) trait -> ???? T1 or nil (T2>>c1) trait (T2>>c2) trait -> ???? T2 or nil" self assert: (AUsingTrait2>>#foo) trait isNil. self assert: (AUsingTrait2>>#c3) trait = Trait2

Oct. 7, 2008

Re: [Pharo-project] Re: Universe Browser - search

by Simon Kirk

Sorry Damian: I would, but I'm afraid I don't understand what the fix actually is as described in that mantis bug. Cheers, Simon On 7 Oct 2008, at 06:44, Damien Cassou wrote: > On Mon, Oct 6, 2008 at 9:40 PM, Dan Corneanu > <dan.corneanu(a)gmail.com> wrote: >>> It has a search, but the last time I tried it it didn't actually >>> find >>> anything for any given string (perhaps I just had a bad experience) >> >> Neither did I :) > > Would you mind trying the following fix and tell me if it works? > http://bugs.squeak.org/view.php?id=6798 > > -- > 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) > _______________________________________________ > 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

Oct. 7, 2008

Re: [Pharo-project] One of the most active projects on GForge

by Alexandre Bergel

Yep, and no announce has been made yet... Cheers, Alexandre On 7 Oct 2008, at 10:06, Damien Cassou wrote: > 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) > _______________________________________________ > 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