Hi,
As we can not very easily decide if we are inside a test execution or not there was the idea to have special #halt messages This PR implements them: There is now #haltIfInsideTest and #haltfOutsideTest. In addition, the PR adds a helper method to make checking if the current execution environment is a test run a bit easier: "CurrentExecutionEnvironment value isTest”. Marcus
|
On 3 April 2018 at 03:12, Marcus Denker <[hidden email]> wrote:
Should the standard #halt default to one of these? Or left as is? (I've no clue, just the question arises). cheers -ben |
I would keep it for now as is.. it is the simplest to have one “halt” that always halts and then variants (there is halt once, too, which makes often more sense than #halt). Marcus |
+1
Doru > On Apr 3, 2018, at 9:09 AM, Marcus Denker <[hidden email]> wrote: > > > >> On 3 Apr 2018, at 00:19, Ben Coman <[hidden email]> wrote: >> >> >> >> On 3 April 2018 at 03:12, Marcus Denker <[hidden email]> wrote: >> Hi, >> >> As we can not very easily decide if we are inside a test execution or not there was the idea to have special #halt messages >> >> https://pharo.fogbugz.com/f/cases/20151/new-halt-messages >> >> This PR implements them: >> >> https://github.com/pharo-project/pharo/pull/1177 >> >> There is now #haltIfInsideTest and #haltfOutsideTest. I >> >> Should the standard #halt default to one of these? Or left as is? (I've no clue, just the question arises). >> > I would keep it for now as is.. it is the simplest to have one “halt” that always halts and then variants (there > is halt once, too, which makes often more sense than #halt). > > Marcus -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with." |
In reply to this post by Marcus Denker-4
+ 1
I really want to use these new friends because I use this pattern really a lot when coding. Tx I wanted to do that during the last sprint. On Tue, Apr 3, 2018 at 9:09 AM, Marcus Denker <[hidden email]> wrote: > > > On 3 Apr 2018, at 00:19, Ben Coman <[hidden email]> wrote: > > > > On 3 April 2018 at 03:12, Marcus Denker <[hidden email]> wrote: >> >> Hi, >> >> As we can not very easily decide if we are inside a test execution or not >> there was the idea to have special #halt messages >> >> https://pharo.fogbugz.com/f/cases/20151/new-halt-messages >> >> This PR implements them: >> >> https://github.com/pharo-project/pharo/pull/1177 >> >> There is now #haltIfInsideTest and #haltfOutsideTest. I > > > Should the standard #halt default to one of these? Or left as is? (I've no > clue, just the question arises). > > I would keep it for now as is.. it is the simplest to have one “halt” that > always halts and then variants (there > is halt once, too, which makes often more sense than #halt). > > Marcus > |
In reply to this post by Marcus Denker-4
Nice addition!
I should say that names are not really intention revealing. What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ?
|
Administrator
|
demarey wrote
> What about haltIfTestExecutionEnvironment and > haltIfDefaultExecutionEnvironment ? I thought the names were okay. What did you think was unclear about them? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
> Le 4 avr. 2018 à 04:34, Sean P. DeNigris <[hidden email]> a écrit : > > demarey wrote >> What about haltIfTestExecutionEnvironment and >> haltIfDefaultExecutionEnvironment ? > > I thought the names were okay. What did you think was unclear about them? At a first look #haltInsideTest and #haltOutsideTest do not tell me that they are conditional breakpoints. maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest |
Would it be possible to instead have a #haltIf object to which you can send additional conditions? E.g. self haltIf insideTest self haltIf outsideTest Makes it (imho) a bit more readable, adds just a single method to Object, and allows for more potential extensions... self haltIf nil. self haltIf count: 3. etc? Peter On Wed, Apr 4, 2018 at 8:36 AM, Christophe Demarey <[hidden email]> wrote:
|
That could be nice!! Maybe having a prototype allows us to see more usages! On Wed, Apr 4, 2018 at 9:58 AM, Peter Uhnák <[hidden email]> wrote:
Pablo Tesone.
[hidden email] |
In reply to this post by demarey
This is fun but I was confused and when I read with the if it makes a
lot more sense. Tx christophe On Wed, Apr 4, 2018 at 8:36 AM, Christophe Demarey <[hidden email]> wrote: > >> Le 4 avr. 2018 à 04:34, Sean P. DeNigris <[hidden email]> a écrit : >> >> demarey wrote >>> What about haltIfTestExecutionEnvironment and >>> haltIfDefaultExecutionEnvironment ? >> >> I thought the names were okay. What did you think was unclear about them? > > At a first look #haltInsideTest and #haltOutsideTest do not tell me that they are conditional breakpoints. > maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest |
In reply to this post by Peter Uhnak
Why not
RIght now I would like to use them to see how they fit my process. On Wed, Apr 4, 2018 at 9:58 AM, Peter Uhnák <[hidden email]> wrote: > Would it be possible to instead have a #haltIf object to which you can send > additional conditions? > > E.g. > > self haltIf insideTest > self haltIf outsideTest > > Makes it (imho) a bit more readable, adds just a single method to Object, > and allows for more potential extensions... > > self haltIf nil. > self haltIf count: 3. > > etc? > > Peter > > On Wed, Apr 4, 2018 at 8:36 AM, Christophe Demarey > <[hidden email]> wrote: >> >> >> > Le 4 avr. 2018 à 04:34, Sean P. DeNigris <[hidden email]> a écrit >> > : >> > >> > demarey wrote >> >> What about haltIfTestExecutionEnvironment and >> >> haltIfDefaultExecutionEnvironment ? >> > >> > I thought the names were okay. What did you think was unclear about >> > them? >> >> At a first look #haltInsideTest and #haltOutsideTest do not tell me that >> they are conditional breakpoints. >> maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest > > |
Administrator
|
In reply to this post by Peter Uhnak
Peter Uhnák wrote
> Would it be possible to instead have a #haltIf object to which you can > send > additional conditions? Maybe we could use that as an excuse to clean more halting out of object completely e.g. self halt now self halt once self halt ifInsideTest self halt ifOutsideTest self halt xyz Although IIRC when we first started cleaning the idea was too eventually remove all halt-related stuff from Object and only have `Halt xyz`. At the time, it seemed that was a little too scary, but even today I do not understand what objectively is gained by `self halt` vs. `Halt now`… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
If we remove self halt, then I won't be able to use `1halt.`. :-D which is actually what I always do, because writing `self halt` is 4 characters tooo long. :) On Wed, Apr 4, 2018 at 9:40 PM, Sean P. DeNigris <[hidden email]> wrote: Peter Uhnák wrote |
On 4 April 2018 at 22:20, Peter Uhnák <[hidden email]> wrote:
> If we remove self halt, then I won't be able to use `1halt.`. :-D which is > actually what I always do, because writing `self halt` is 4 characters tooo > long. :) > > On Wed, Apr 4, 2018 at 9:40 PM, Sean P. DeNigris <[hidden email]> > wrote: >> >> Peter Uhnák wrote >> > Would it be possible to instead have a #haltIf object to which you can >> > send >> > additional conditions? >> >> Maybe we could use that as an excuse to clean more halting out of object >> completely e.g. >> self halt now >> self halt once >> self halt ifInsideTest >> self halt ifOutsideTest >> self halt xyz >> >> Although IIRC when we first started cleaning the idea was too eventually >> remove all halt-related stuff from Object and only have `Halt xyz`. At the >> time, it seemed that was a little too scary, but even today I do not >> understand what objectively is gained by `self halt` vs. `Halt now`… One (very small) advantage of having 'self halt' is that a few times I've had a single, long, expression that I want to halt in, and since #halt returns self it is easy to insert it in the middle of an expression. Cheers, Alistair |
In reply to this post by demarey
To long and too implementation centered. I would even shorten it to haltIfTest and haltIfNotTest.
|
In reply to this post by Peter Uhnak
> On 4 Apr 2018, at 09:58, Peter Uhnák <[hidden email]> wrote: > > Would it be possible to instead have a #haltIf object to which you can send additional conditions? > > E.g. > > self haltIf insideTest > self haltIf outsideTest > > Makes it (imho) a bit more readable, adds just a single method to Object, and allows for more potential extensions... > > self haltIf nil. > self haltIf count: 3. > Interesting. I will make a not. Another thing to think about is that all this “combination” stuff might be where a BreakPoint system with a good UI actually starts to be better than a textual halt. The power of the Smalltalk #halt lies to some extend it its radical simplicity. Marcus |
In reply to this post by alistairgrant
> On 5 Apr 2018, at 07:26, Alistair Grant <[hidden email]> wrote: > > On 4 April 2018 at 22:20, Peter Uhnák <[hidden email]> wrote: >> If we remove self halt, then I won't be able to use `1halt.`. :-D which is >> actually what I always do, because writing `self halt` is 4 characters tooo >> long. :) >> >> On Wed, Apr 4, 2018 at 9:40 PM, Sean P. DeNigris <[hidden email]> >> wrote: >>> >>> Peter Uhnák wrote >>>> Would it be possible to instead have a #haltIf object to which you can >>>> send >>>> additional conditions? >>> >>> Maybe we could use that as an excuse to clean more halting out of object >>> completely e.g. >>> self halt now >>> self halt once >>> self halt ifInsideTest >>> self halt ifOutsideTest >>> self halt xyz >>> >>> Although IIRC when we first started cleaning the idea was too eventually >>> remove all halt-related stuff from Object and only have `Halt xyz`. At the >>> time, it seemed that was a little too scary, but even today I do not >>> understand what objectively is gained by `self halt` vs. `Halt now`… > > One (very small) advantage of having 'self halt' is that a few times > I've had a single, long, expression that I want to halt in, and since > #halt returns self it is easy to insert it in the middle of an > expression. > Yes, and we should make sure to keep that. Marcus |
In reply to this post by Marcus Denker-4
2018-04-05 9:10 GMT+02:00 Marcus Denker <[hidden email]>:
+1
|
In reply to this post by Marcus Denker-4
> On 5 Apr 2018, at 09:12, Marcus Denker <[hidden email]> wrote: > > > >> On 4 Apr 2018, at 09:58, Peter Uhnák <[hidden email]> wrote: >> >> Would it be possible to instead have a #haltIf object to which you can send additional conditions? >> >> E.g. >> >> self haltIf insideTest >> self haltIf outsideTest >> >> Makes it (imho) a bit more readable, adds just a single method to Object, and allows for more potential extensions... >> >> self haltIf nil. >> self haltIf count: 3. >> > > Interesting. I will make a not. > note… I will make a note. Not a not. Marcus |
Free forum by Nabble | Edit this page |