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

Re: [Pharo-project] Some clearifications

by StÃ©phane Ducasse

On Oct 6, 2008, at 3:46 AM, Bill Schwab wrote: > Stef, > > Would you not simply fix B2? I could easily be missing something; > perhaps B2 is an external package that works in Squeak but clobbers > Pharo?? > Is it something else? No this is the same in all Smalltalk, if B3 was based on B2. then you have to remove all the streamed elements based on B2. > > > FWIW, I envision a stable release and active development, much as > happens on Squeak, just consistent with the Pharo frame of mind. New > contributions would tend to go into the development release, some that > are of near-term interest could be tested and "back-ported" (aka > installed in the next stable release). Every so often, I would > further > envision doing some type of export of all my stable-version Pharo code > and loading into the development release to look for problems or to > verify that all is well. yes. I think that we can consider that we already have that when we do not publish a new image. We can say that the image is the stable version while the stream elements from the last image are the active part. > Making that export/import cycle as simple as possible will be a useful > step in helping people test the development images. No export. We publish packages > Understanding the > existing tools is one of my next goals. For Dolphin, I wrote a tool > called Migrate that helped to sniff out my packages and overrides and > get them loaded in a new image. I would like to find that there is > something so slick that Migrate is not needed for Pharo. Failing > that, > I will port it over, once I figure out what it should do. > Pharo will change. So you will have to port because even if you press a button that load new components they may change something you rely on. > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 10/05/08 5:41 PM >>> >> >> Taking all together I think we need to split upstream. As long as >> there >> is only one upstream you can't check that _before_ it gets published. >> And people see a version in the upstream as the next stable thing. So >> we need a side channel for integration and testing. > > This sounds like a good idea. > Now I do not know if this could work because if we integrate > B1 B2 B3 B4 > > and there is a problem we cannot really cancel B2 just > add B5 to fix > it. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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 StÃ©phane Ducasse

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 >

Oct. 6, 2008

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

by Alexandre Bergel

Traits are not essential. However they simplify the design of complex class hierarchies. Various case studies show this. Last time I use traits when coding was to share identical visit* methods in visitors that do not belong to the same class hierarchies (since they evaluate different interpreted languages). Cheers, Alexandre On 6 Oct 2008, at 03:35, 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by Norbert Hartl

Stef, I don't have an ifEmptyOrNil: in my image only isEmptyOrNil and that is specified for Collection and UndefinedObject. Did I miss something? Norbert On Sun, 2008-10-05 at 11:31 +0200, StÃ©phane Ducasse wrote: > Hi > > I would like to have your take on that one: > > isEmpty > "Answer whether the receiver contains any elements." > > ^self size = 0 > > Why do we need ifEmptyOrNil: > > isEmptyOrNil > "Answer whether the receiver contains any elements, or is nil. > Useful in numerous situations where one > wishes the same reaction to an empty collection or to nil" > ^ self isEmpty > > > why can we use isEmpty: or ifEmpty: aBlock > > ifEmpty: aBlock > "Evaluate the block if I'm empty" > ^ self isEmpty ifTrue: aBlock > > Then from an implementation point of view ifEmptyOrNil: is bogus since > it never returns nil (or should not and is also ill-specified). > I checked ANSI and this is really a boolean. > > I'm the mood to deprecate this method. > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2008

Re: [Pharo-project] Some clearifications

by Norbert Hartl

On Sun, 2008-10-05 at 23:41 +0200, StÃ©phane Ducasse wrote: > > > > Taking all together I think we need to split upstream. As long as > > there > > is only one upstream you can't check that _before_ it gets published. > > And people see a version in the upstream as the next stable thing. So > > we need a side channel for integration and testing. > > This sounds like a good idea. > Now I do not know if this could work because if we integrate > B1 B2 B3 B4 > > and there is a problem we cannot really cancel B2 just add B5 to fix > it. > I think there are cases where you have to redo B2, e.g. if it is not loadable. Then just redo it and post it to the list. Everyone using a development upstream should read the list. Removing B2 is not necessary because B5 undoes the problem of B2. And that is exactly the reason for doing an development upstream. You can undo things before merging the whole thing into the official upstream. The official one does not contain anything faulty from B2. What might be a problem is that version numbers on dev are getting larger faster than on the official one (if you use a single number). So the usual development case is that you take the latest official release S1 and do subsequent D1, D2, D3, D4 enhancements. If you think everything is stable and worth publishing you merge D4 into S1 and create S2. Based on that you do D5, D6, D7 and so on. About the naming scheme I'm not sure. I would prefer something like stable version 1 and development version 1.1, 1.2, 1.3 than stable version 2 and development 2.1, 2.2. So there is no doubt which development version belongs to which stable version. But I don't know how much work it will be to get it work that way. Norbert

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by David Pennell

Stef, I would expect to see another implementation of ifEmptyOrNil on UndefinedObject that returns true. I've seen it used productively for defensive coding in frameworks, where you may get nil instead of an empty collection passed to you. -david On Sun, Oct 5, 2008 at 8:28 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Stef, > > I suspect your mood is appropriate. Most likely, it masks a failure to > initialize something to a collection. Unless there is a performance > argument (e.g. many are created, few are actually used, or something > like that??), then it probably should go. > > Bill > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > >>> stephane.ducasse(a)inria.fr 10/05/08 5:31 AM >>> > Hi > > I would like to have your take on that one: > > isEmpty > "Answer whether the receiver contains any elements." > > ^self size = 0 > > Why do we need ifEmptyOrNil: > > isEmptyOrNil > "Answer whether the receiver contains any elements, or > is nil. > Useful in numerous situations where one > wishes the same reaction to an empty collection or to > nil" > ^ self isEmpty > > > why can we use isEmpty: or ifEmpty: aBlock > > ifEmpty: aBlock > "Evaluate the block if I'm empty" > ^ self isEmpty ifTrue: aBlock > > Then from an implementation point of view ifEmptyOrNil: is bogus since > it never returns nil (or should not and is also ill-specified). > I checked ANSI and this is really a boolean. > > I'm the mood to deprecate this method. > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 6, 2008

Re: [Pharo-project] Some clearifications

by Bill Schwab

Stef, Would you not simply fix B2? I could easily be missing something; perhaps B2 is an external package that works in Squeak but clobbers Pharo?? Is it something else? FWIW, I envision a stable release and active development, much as happens on Squeak, just consistent with the Pharo frame of mind. New contributions would tend to go into the development release, some that are of near-term interest could be tested and "back-ported" (aka installed in the next stable release). Every so often, I would further envision doing some type of export of all my stable-version Pharo code and loading into the development release to look for problems or to verify that all is well. Making that export/import cycle as simple as possible will be a useful step in helping people test the development images. Understanding the existing tools is one of my next goals. For Dolphin, I wrote a tool called Migrate that helped to sniff out my packages and overrides and get them loaded in a new image. I would like to find that there is something so slick that Migrate is not needed for Pharo. Failing that, I will port it over, once I figure out what it should do. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 10/05/08 5:41 PM >>> > > Taking all together I think we need to split upstream. As long as > there > is only one upstream you can't check that _before_ it gets published. > And people see a version in the upstream as the next stable thing. So > we need a side channel for integration and testing. This sounds like a good idea. Now I do not know if this could work because if we integrate B1 B2 B3 B4 and there is a problem we cannot really cancel B2 just add B5 to fix it. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2008

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

by Bill Schwab

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

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by Bill Schwab

Stef, I suspect your mood is appropriate. Most likely, it masks a failure to initialize something to a collection. Unless there is a performance argument (e.g. many are created, few are actually used, or something like that??), then it probably should go. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 10/05/08 5:31 AM >>> Hi I would like to have your take on that one: isEmpty "Answer whether the receiver contains any elements." ^self size = 0 Why do we need ifEmptyOrNil: isEmptyOrNil "Answer whether the receiver contains any elements, or is nil. Useful in numerous situations where one wishes the same reaction to an empty collection or to nil" ^ self isEmpty why can we use isEmpty: or ifEmpty: aBlock ifEmpty: aBlock "Evaluate the block if I'm empty" ^ self isEmpty ifTrue: aBlock Then from an implementation point of view ifEmptyOrNil: is bogus since it never returns nil (or should not and is also ill-specified). I checked ANSI and this is really a boolean. I'm the mood to deprecate this method. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2008

Re: [Pharo-project] Some clearifications

by StÃ©phane Ducasse

> > Taking all together I think we need to split upstream. As long as > there > is only one upstream you can't check that _before_ it gets published. > And people see a version in the upstream as the next stable thing. So > we need a side channel for integration and testing. This sounds like a good idea. Now I do not know if this could work because if we integrate B1 B2 B3 B4 and there is a problem we cannot really cancel B2 just add B5 to fix it. Stef

Oct. 5, 2008