- Pharo-dev - lists.pharo.org

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

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

by Damien Cassou

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)

Oct. 7, 2008

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

by Damien Cassou

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)

Oct. 7, 2008

Re: [Pharo-project] Re: about ifEmptyOrNil:

by Bill Schwab

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

Oct. 6, 2008

Re: [Pharo-project] Some clearifications

by Michael Roberts

given what I consider to be constraints - and these are not complaints at all, just observation which I am quite happy with 1) 3 harvesters 2) minimal software support for sophisticated branch or release management I wonder if it would be better to put more effort into expectation management amongst the community. i.e define and document what the update stream represents, and what a 'release' represents. I think it is fantastic we have an update stream. It shows progress, and allows interested folk to test the integration by the harvesters and provide feedback. I do not consider each update to be a 'release' or stable. It is not blessed to me like updates that used to come out of Squeak Central. To me it just shows progress, even if it introduces bugs. A bug can be reported on the list/tracker, feedback can help the next update. each step we move forwards, in a small controlled fashion. Perhaps once a milestone is reached, or some considered point in the future - a release is declared and built. Perhaps people who don't want to be on the development-edge do not update from the update stream until a time that it is recommended. Updates are addictive I find, but I have set my expectations and enjoy the progress. just my thoughts, I would prefer the harvesting and update process is not complicated trying to satisfy too many requirements. From my point of view it is important we can test the integration represented in the update stream, since there should be a way that we can scale the testing amongst a wider group outside the harvesters. It is perhaps interesing, (or not), that I was discussing something similar with Yann the other day. We were talking about MCC and what exactly it was - we did not really know. The next day a post on the Seaside list mentioned the move to universes in that context and constraints. Yann and I were wondering if it would be useful (or not) to have a bit more of the model of Envy maps in Monticello. We did not have any great ideas, just a feeling that Universes, MC, MCC, SM, Squeak SVN etc just demonstrate many forces that pull the needs for configuration management and version control in different directions. I think trying to solve this general problem: updates, branches, releases, backporting, distribution, approval, integration, etc is just very hard. My suggestion with Pharo would not be to do anything particularly clever at the moment as long as everyone knows what is to be expected from the current process. That way we keep moving forward without needing to reinvent too much in one go. cheers, Mike

Oct. 6, 2008

Re: [Pharo-project] Re: about ifEmptyOrNil:

by Michael Roberts

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 >

Oct. 6, 2008

Re: [Pharo-project] about class abtractness

by Michael Roberts

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 >

Oct. 6, 2008