- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [1.1] Object>>initialExtent

by Igor Stasenko

On 4 March 2010 21:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > The user interface or the model should define the initialExtent > I do not understand why > Â Â Â Â 1 initialExtent makes sense. > :) me either. Obviously the problem is not in one who implements that message, but to whom this message should be directed. > We have to define initialExtent to some model. > > Stef > >> I ran into this as well. Â I tried to avoid triggering the deprecation, >> to see if the model understood initialExtent before sending it and >> guarding for nil models and things like that. otherwise just >> dispatching to the default extent, however this is difficult because >> all objects understand initialExtent! i needed a method >> respondsToButNotInObject:... at that point I got distracted. Â it is >> ugly to do this deep respondsTo: check so I was not sure what the >> correct way of approaching this deprecation was. I assumed someone had >> a nice solution when they deprecated it? >> >> Mike >> >> On Thu, Mar 4, 2010 at 5:49 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >>> Hi! >>> >>> I do not have a solution, but Object>>initialExtent was recently >>> deprecated and this causes great usability problem. This deprecation >>> is very valuable for a clean UI separation. However, I have a warning >>> deprecation each time a window is open. The reason stems from the >>> method: >>> >>> SystemWindow>>initialExtent >>> Â Â Â Â ^ model initialExtent >>> >>> For now, in my image, I suppressed this deprecation. >>> Again, I do not have a clean solution. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 5, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

The problem is that some ancestor versions disappeared, what makes it impossible to merge. We've manually integrated the delta into: Name: Tests-lr.79 Author: lr Time: 5 March 2010, 12:16:05 pm UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 Ancestors: Tests-MichaelRueger.78 - merged Jorges Code Lukas On 5 March 2010 11:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Jorge > > could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? > > Stef > > >> Hi Adrian, >> >> Sorry for the delay, too many things today. >> >> Ok, I added 17 test to Tests-Compiler which model the cases of >> shadowing, at least the ones I could come up with. I also modified the >> Encoder>>bindTemp: in order to make it a little bit more intention >> revealing. >> >> My changes are in: >> >> Â Â Â Â Â Â Â Â Â Â Â Compiler-JorgeRessia.144 >> Â Â Â Â Â Â Â Â Â Â Â Tests-JorgeRessia.46 >> >> Some comments: >> >> - In order to test the not interactive mode I had to mock the >> Transcript. I could not find a better solution, if anybody has a >> better one just let me know I'll change it. >> - There is a special case which is that when you are NOT in >> interactive mode if the shadowed variable is a temp then the syntax >> error is triggered as in interactive mode. This is the behavior >> implemented before I did the changes. Is that what we want? >> - I added this test to Tests-Compiler package, I would have preferred >> to add them to Compiler-Tests but there was nothing there. >> >> Cheers, >> >> Jorge >> >> On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> Hi Jorge, >>> >>> Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! >>> >>> Cheers, >>> Adrian >>> >>> On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: >>> >>>> Hi Adrian, >>>> >>>> Yep, I have the same problem as you. My idea was to make it work as >>>> before without completely changing it. Basically because I did not >>>> have the test support to validate my changes. >>>> Anyhow, what I propose is to write a bunch of tests for every case >>>> that we know and then if new cases show up add them to the test suite. >>>> And then play with the code. >>>> >>>> I will work on that today, is that ok? >>>> >>>> For the explanation of what is going on is that now node can be an >>>> instance variable node, then the behavior that was there was not >>>> appropriate in the sense that instance variable nodes do not >>>> understand #scope. >>>> However, why this validation "(node isTemp or: [requestor >>>> interactive])" was there in the first place is not that clear to me, >>>> but it's been there since 1999. >>>> >>>> I'll try to build the tests and come up with a better solution. >>>> >>>> Cheers, >>>> >>>> Jorge >>>> >>>> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>> Jorge, >>>>> >>>>> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >>>>> >>>>> This is the code: >>>>> >>>>> "When non-interactive raise the error only if its a duplicate" >>>>> (node isTemp or: [requestor interactive]) >>>>> Â Â Â Â ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [^self notify:'Name is already defined' ]] >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >>>>> >>>>>> 11243 >>>>>> ----- >>>>>> >>>>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>>>>> Â Â Â Problem fixed: >>>>>> We cannot have twice the same block arg in a method >>>>>> >>>>>> Â Â Â [:each | each ...] >>>>>> Â Â Â [:each | each ...] >>>>>> >>>>>> THANKS jorge :) >>>>>> Do you like good bio beer? >>>>>> >>>>>> 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 >>> >> >> _______________________________________________ >> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

March 5, 2010

[Pharo-project] Add Alien in 1.1 (Issue 1360)

by Schmidt, Marco

I have updated issue 1360 with a zip file containing my current build. The zip-File was too large for the mailing list... Marco Schmidt

March 5, 2010

[Pharo-project] [update 1.1] #11244

by StÃ©phane Ducasse

- remove the default password squeak in the MCHttpRepository creation template - Introduction of tests for validating the different use cases of Shadowing in CompilerTest. - Improvement in the Encoder>>bindTemp: method in order to make explicit the decisions Thanks Jorge and lukas :)

March 5, 2010

Re: [Pharo-project] [update 1.1] #11243

by StÃ©phane Ducasse

Jorge could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? Stef > Hi Adrian, > > Sorry for the delay, too many things today. > > Ok, I added 17 test to Tests-Compiler which model the cases of > shadowing, at least the ones I could come up with. I also modified the > Encoder>>bindTemp: in order to make it a little bit more intention > revealing. > > My changes are in: > > Compiler-JorgeRessia.144 > Tests-JorgeRessia.46 > > Some comments: > > - In order to test the not interactive mode I had to mock the > Transcript. I could not find a better solution, if anybody has a > better one just let me know I'll change it. > - There is a special case which is that when you are NOT in > interactive mode if the shadowed variable is a temp then the syntax > error is triggered as in interactive mode. This is the behavior > implemented before I did the changes. Is that what we want? > - I added this test to Tests-Compiler package, I would have preferred > to add them to Compiler-Tests but there was nothing there. > > Cheers, > > Jorge > > On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> Hi Jorge, >> >> Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! >> >> Cheers, >> Adrian >> >> On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: >> >>> Hi Adrian, >>> >>> Yep, I have the same problem as you. My idea was to make it work as >>> before without completely changing it. Basically because I did not >>> have the test support to validate my changes. >>> Anyhow, what I propose is to write a bunch of tests for every case >>> that we know and then if new cases show up add them to the test suite. >>> And then play with the code. >>> >>> I will work on that today, is that ok? >>> >>> For the explanation of what is going on is that now node can be an >>> instance variable node, then the behavior that was there was not >>> appropriate in the sense that instance variable nodes do not >>> understand #scope. >>> However, why this validation "(node isTemp or: [requestor >>> interactive])" was there in the first place is not that clear to me, >>> but it's been there since 1999. >>> >>> I'll try to build the tests and come up with a better solution. >>> >>> Cheers, >>> >>> Jorge >>> >>> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>> Jorge, >>>> >>>> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >>>> >>>> This is the code: >>>> >>>> "When non-interactive raise the error only if its a duplicate" >>>> (node isTemp or: [requestor interactive]) >>>> ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>>> ifFalse: [^self notify:'Name is already defined' ]] >>>> >>>> Cheers, >>>> Adrian >>>> >>>> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >>>> >>>>> 11243 >>>>> ----- >>>>> >>>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>>>> Problem fixed: >>>>> We cannot have twice the same block arg in a method >>>>> >>>>> [:each | each ...] >>>>> [:each | each ...] >>>>> >>>>> THANKS jorge :) >>>>> Do you like good bio beer? >>>>> >>>>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 5, 2010

[Pharo-project] AlienPlugin

by StÃ©phane Ducasse

Excellent marco!!!!! This is an excellent news! Stef Begin forwarded message: > From: "Schmidt, Marco" <Marco.Schmidt(a)eads.com> > Date: March 5, 2010 11:06:10 AM GMT+01:00 > To: <Pharo-project(a)lists.gforge.inria.fr> > Subject: Test Alien on Win32... > > > Finally I had time to give AlienPlugin another try under Win32. Here it is. At the moment Iâm testing and building an interface to libcurl. > My work is based on the current vm-source (Andreas Raab, version 3.11.5) with some modifications harvested from the newspeak-source code. I have a local git-repository with all patches needed ready to review and integrate. Should we use github to mirror the squeakvm-repo? > > Marco Schmidt

March 5, 2010

Re: [Pharo-project] Having fun with booleans

by Igor Stasenko

On 5 March 2010 11:17, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: >> On 5 mar 2010, at 09.33, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> >> >>> The problem is the side effects, is suddenly Boolean>>and: stops to >>> be lazy. >>> Possibly evaluating blocks that shouldn't be evaluated. >>> >> No, but there is one subtle difference anyway: both #and: and #or: >> will return a Boolean (the receiver) if the block argument isn't >> executed, whereas #ifTrue: and #ifFalse: will return nil in that case. >> So if you do something with the return value, then the bytecode will >> be different for sure. >> >> But it's academic anyway: the use of #and: and #or: gives the reader a >> very strong hint that the argument block (if executed) is supposed to >> return a Boolean, so to use it purely for branching in the code could >> be seen as misleading. >> >> -- >> Cheers, >> Peter >> > I like that argument turned on its head, namely that ifTrue: ifFalse: > gives the reader a very strong hint that the argument blocks are used > purely for branching, thus using them to (eventually) return a boolean > can be seen as misleading :) > > i.e. I tend to prefer to use Igors and: example for code I often see written > > a < b ifTrue: [... a couple of actions, then returning true or false ...] > Â Â Â Â ifFalse: [^false] > yes, sometimes i find it inconvenient ,that i can't do chaining: (a<b ifTrue: [ self foo. c<d ]) ifTrue: [ ... ] since #ifTrue: answers nil if condition evaluated to false. > Cheers, > Henry >> >>> Fernando >>> >>> On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: >>> >>> >>>> Hello, >>>> I just realized, that one can completely avoid using ifTrue/ifFalse >>>> branches, but use #or: and #and: instead. >>>> >>>> a > b ifTrue: [ ... ] >>>> could be written as: >>>> a > b and: [ ... ] >>>> >>>> a > b ifFalse: [ ... ] >>>> could be written as: >>>> a > b or: [ ... ] >>>> >>>> and >>>> a > b ifTrue: [ self foo ] ifFalse: [ self bar ] >>>> could be written as: >>>> >>>> a > b and: [ self foo]; or:[ self bar ] >>>> >>>> :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 > -- Best regards, Igor Stasenko AKA sig.

March 5, 2010

Re: [Pharo-project] Having fun with booleans

by Peter Hugosson-Miller

On 5 mar 2010, at 10.17, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: >> On 5 mar 2010, at 09.33, Fernando olivero <oliverof(a)lu.unisi.ch> >> wrote: >> >> >>> The problem is the side effects, is suddenly Boolean>>and: stops to >>> be lazy. >>> Possibly evaluating blocks that shouldn't be evaluated. >>> >> No, but there is one subtle difference anyway: both #and: and #or: >> will return a Boolean (the receiver) if the block argument isn't >> executed, whereas #ifTrue: and #ifFalse: will return nil in that >> case. >> So if you do something with the return value, then the bytecode will >> be different for sure. >> >> But it's academic anyway: the use of #and: and #or: gives the >> reader a >> very strong hint that the argument block (if executed) is supposed to >> return a Boolean, so to use it purely for branching in the code could >> be seen as misleading. >> >> -- >> Cheers, >> Peter >> > I like that argument turned on its head, namely that ifTrue: ifFalse: > gives the reader a very strong hint that the argument blocks are used > purely for branching, thus using them to (eventually) return a boolean > can be seen as misleading :) > > i.e. I tend to prefer to use Igors and: example for code I often see > written > > a < b ifTrue: [... a couple of actions, then returning true or > false ...] > ifFalse: [^false] And I'm definitely with you on that score! In fact it's how I decide which method to use :-) -- Cheers, Peter > Cheers, > Henry >> >>> Fernando >>> >>> On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: >>> >>> >>>> Hello, >>>> I just realized, that one can completely avoid using ifTrue/ifFalse >>>> branches, but use #or: and #and: instead. >>>> >>>> a > b ifTrue: [ ... ] >>>> could be written as: >>>> a > b and: [ ... ] >>>> >>>> a > b ifFalse: [ ... ] >>>> could be written as: >>>> a > b or: [ ... ] >>>> >>>> and >>>> a > b ifTrue: [ self foo ] ifFalse: [ self bar ] >>>> could be written as: >>>> >>>> a > b and: [ self foo]; or:[ self bar ] >>>> >>>> :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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

March 5, 2010

Re: [Pharo-project] Having fun with booleans

by Henrik Johansen

Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: > On 5 mar 2010, at 09.33, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > > >> The problem is the side effects, is suddenly Boolean>>and: stops to >> be lazy. >> Possibly evaluating blocks that shouldn't be evaluated. >> > No, but there is one subtle difference anyway: both #and: and #or: > will return a Boolean (the receiver) if the block argument isn't > executed, whereas #ifTrue: and #ifFalse: will return nil in that case. > So if you do something with the return value, then the bytecode will > be different for sure. > > But it's academic anyway: the use of #and: and #or: gives the reader a > very strong hint that the argument block (if executed) is supposed to > return a Boolean, so to use it purely for branching in the code could > be seen as misleading. > > -- > Cheers, > Peter > I like that argument turned on its head, namely that ifTrue: ifFalse: gives the reader a very strong hint that the argument blocks are used purely for branching, thus using them to (eventually) return a boolean can be seen as misleading :) i.e. I tend to prefer to use Igors and: example for code I often see written a < b ifTrue: [... a couple of actions, then returning true or false ...] ifFalse: [^false] Cheers, Henry > >> Fernando >> >> On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: >> >> >>> Hello, >>> I just realized, that one can completely avoid using ifTrue/ifFalse >>> branches, but use #or: and #and: instead. >>> >>> a > b ifTrue: [ ... ] >>> could be written as: >>> a > b and: [ ... ] >>> >>> a > b ifFalse: [ ... ] >>> could be written as: >>> a > b or: [ ... ] >>> >>> and >>> a > b ifTrue: [ self foo ] ifFalse: [ self bar ] >>> could be written as: >>> >>> a > b and: [ self foo]; or:[ self bar ] >>> >>> :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 > > >

March 5, 2010

Re: [Pharo-project] Having fun with booleans

by Peter Hugosson-Miller

On 5 mar 2010, at 09.33, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > The problem is the side effects, is suddenly Boolean>>and: stops to > be lazy. > Possibly evaluating blocks that shouldn't be evaluated. No, but there is one subtle difference anyway: both #and: and #or: will return a Boolean (the receiver) if the block argument isn't executed, whereas #ifTrue: and #ifFalse: will return nil in that case. So if you do something with the return value, then the bytecode will be different for sure. But it's academic anyway: the use of #and: and #or: gives the reader a very strong hint that the argument block (if executed) is supposed to return a Boolean, so to use it purely for branching in the code could be seen as misleading. -- Cheers, Peter > Fernando > > On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: > >> Hello, >> I just realized, that one can completely avoid using ifTrue/ifFalse >> branches, but use #or: and #and: instead. >> >> a > b ifTrue: [ ... ] >> could be written as: >> a > b and: [ ... ] >> >> a > b ifFalse: [ ... ] >> could be written as: >> a > b or: [ ... ] >> >> and >> a > b ifTrue: [ self foo ] ifFalse: [ self bar ] >> could be written as: >> >> a > b and: [ self foo]; or:[ self bar ] >> >> :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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

March 5, 2010