question on return from blocks and ensure: blocks 
Author Message
 question on return from blocks and ensure: blocks

I will probably get taken to task by the experts for even asking
this, but here goes.

If I create a method like this

runBlock: aBlock
        [
                ret := aBlock value
        ] ensure: [... do my clean up ...]
        ^ret

AND if "aBlock" contains a return which is important,
I cannot tell what it is in my ensure: block.

Consider the following invocation

myMethod
        self runBlock: [
                doAction ifFalse: [^false].
                doAnotherAction ifTrue: [^true].
                doAnotherOne
        ].
        ^true

The cleanup action in my ensure: block wants to do something different
based on a false vs true return.  The specific case is wrapping code
in a database transaction (Gemstone to be exact, but the code is
on the client).  If I get false I want to abort if true commit.

I KNOW I can do this by putting the actions in another method an
saying

myMethod
        ^self runBlock: [self doAllActions]

but in the simple cases it sure is easier to read the code when its
all there in front of you.

The "innerReturn" value is certainly there in the BlockContext
nonLocalReturn handling, its just not available to me.

Anyone thought about this at all?
=================================================================
Dennis Smith, MaSc  --  Cherniak Software Development Corporation
400-10 Commerce Valley Dr E, Thornhill ON Canada  L3T 7N7
Phone: 905.771.7011      FAX: 905.771.6288



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks

Quote:
> I will probably get taken to task by the experts for even asking
> this, but here goes.

> If I create a method like this

> runBlock: aBlock
> [
> ret := aBlock value
> ] ensure: [... do my clean up ...]
> ^ret

> AND if "aBlock" contains a return which is important,
> I cannot tell what it is in my ensure: block.

> Consider the following invocation

> myMethod
> self runBlock: [
> doAction ifFalse: [^false].
> doAnotherAction ifTrue: [^true].
> doAnotherOne
> ].
> ^true

> The cleanup action in my ensure: block wants to do something different
> based on a false vs true return. The specific case is wrapping code
> in a database transaction (Gemstone to be exact, but the code is
> on the client). If I get false I want to abort if true commit.

> I KNOW I can do this by putting the actions in another method an
> saying

> myMethod
> ^self runBlock: [self doAllActions]

> but in the simple cases it sure is easier to read the code when its
> all there in front of you.

> The "innerReturn" value is certainly there in the BlockContext
> nonLocalReturn handling, its just not available to me.

> Anyone thought about this at all?

I think if you're going to use ensure: then don't parcel it up into a
separate method. Try this form:

    | result |

    [self doAction
    ifFalse:
        [result := false]
    ifTrue:
        [self doAnotherAction
            ifTrue: [result := true]
            ifFalse: [self doSomethingElse]]]
    ensure:
        [self doCleanUp].

    ^result

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
Why not implement a "resultEnsure:aBlock" method , where aBlock take as
a single parameter, result from first evaluation block ?

runBlock: ^ aBlock
         [
                 aBlock value
         ] resultEnsure: [:res | ... do my clean up ...]
         ^ret

Quote:

> I will probably get taken to task by the experts for even asking
> this, but here goes.

> If I create a method like this

> runBlock: aBlock
>         [
>                 ret := aBlock value
>         ] ensure: [... do my clean up ...]
>         ^ret

> AND if "aBlock" contains a return which is important,
> I cannot tell what it is in my ensure: block.

> Consider the following invocation

> myMethod
>         self runBlock: [
>                 doAction ifFalse: [^false].
>                 doAnotherAction ifTrue: [^true].
>                 doAnotherOne
>         ].
>         ^true

> The cleanup action in my ensure: block wants to do something different
> based on a false vs true return.  The specific case is wrapping code
> in a database transaction (Gemstone to be exact, but the code is
> on the client).  If I get false I want to abort if true commit.

> I KNOW I can do this by putting the actions in another method an
> saying

> myMethod
>         ^self runBlock: [self doAllActions]

> but in the simple cases it sure is easier to read the code when its
> all there in front of you.

> The "innerReturn" value is certainly there in the BlockContext
> nonLocalReturn handling, its just not available to me.

> Anyone thought about this at all?
> =================================================================
> Dennis Smith, MaSc  --  Cherniak Software Development Corporation
> 400-10 Commerce Valley Dr E, Thornhill ON Canada  L3T 7N7
> Phone: 905.771.7011      FAX: 905.771.6288


--
Pascal HERAUD - Socit ?GIS


http://www.multimania.com/heraudp/
Artis: http://artisweb.cjb.net/ Bire: http://beercollect.cjb.net/
Desacor: http://desacor.cjb.net/


Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
On Thu, 16 Mar 2000 16:19:40 +0100, Pascal Heraud

Quote:

>Why not implement a "resultEnsure:aBlock" method , where aBlock take as
>a single parameter, result from first evaluation block ?

>runBlock: ^ aBlock
>         [
>                 aBlock value
>         ] resultEnsure: [:res | ... do my clean up ...]
>         ^ret

I did -- but it hacked into BlockContext and BlockClosure, and
although I don't mind adding to things like
        Object
        String
or fixing bugs, it bothered me a bit to hack into that internal
a level.  I wondered if anyone else had done it, wanted it,
saw a reason to NOT do it.
Quote:


>> I will probably get taken to task by the experts for even asking
>> this, but here goes.

>> If I create a method like this

>> runBlock: aBlock
>>         [
>>                 ret := aBlock value
>>         ] ensure: [... do my clean up ...]
>>         ^ret

>> AND if "aBlock" contains a return which is important,
>> I cannot tell what it is in my ensure: block.

>> Consider the following invocation

>> myMethod
>>         self runBlock: [
>>                 doAction ifFalse: [^false].
>>                 doAnotherAction ifTrue: [^true].
>>                 doAnotherOne
>>         ].
>>         ^true

>> The cleanup action in my ensure: block wants to do something different
>> based on a false vs true return.  The specific case is wrapping code
>> in a database transaction (Gemstone to be exact, but the code is
>> on the client).  If I get false I want to abort if true commit.

>> I KNOW I can do this by putting the actions in another method an
>> saying

>> myMethod
>>         ^self runBlock: [self doAllActions]

>> but in the simple cases it sure is easier to read the code when its
>> all there in front of you.

>> The "innerReturn" value is certainly there in the BlockContext
>> nonLocalReturn handling, its just not available to me.

>> Anyone thought about this at all?
>> =================================================================
>> Dennis Smith, MaSc  --  Cherniak Software Development Corporation
>> 400-10 Commerce Valley Dr E, Thornhill ON Canada  L3T 7N7
>> Phone: 905.771.7011      FAX: 905.771.6288




Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks

In VisualAge Smalltalk it already works this way (i.e. exactly the way you
want.).  This is a fairly  common requirement however I don't believe the
other VMs do it.

Try this in a workspace.

[
 ^ true
] ensure: [ :result |
  result == true ifTrue: [Transcript cr; show: 'true returned' ].
  result == false ifTrue: [Transcript cr; show: 'false returned' ].
]

[
 ^ false
] ensure: [ :result |
  result == true ifTrue: [Transcript cr; show: 'true returned' ].
  result == false ifTrue: [Transcript cr; show: 'false returned' ]
]

of course, the contents of your block can have any non local return (unlike
my simple example) including a block passed in with a return in it. Note
that in your example below, if aBlock actually has a return statement, you
will never assign to the ret variable because of the non-local return.

/J


Quote:
> I will probably get taken to task by the experts for even asking
> this, but here goes.

> If I create a method like this

> runBlock: aBlock
> [
> ret := aBlock value
> ] ensure: [... do my clean up ...]
> ^ret

> AND if "aBlock" contains a return which is important,
> I cannot tell what it is in my ensure: block.

> Consider the following invocation

> myMethod
> self runBlock: [
> doAction ifFalse: [^false].
> doAnotherAction ifTrue: [^true].
> doAnotherOne
> ].
> ^true

> The cleanup action in my ensure: block wants to do something different
> based on a false vs true return.  The specific case is wrapping code
> in a database transaction (Gemstone to be exact, but the code is
> on the client).  If I get false I want to abort if true commit.

> I KNOW I can do this by putting the actions in another method an
> saying

> myMethod
> ^self runBlock: [self doAllActions]

> but in the simple cases it sure is easier to read the code when its
> all there in front of you.

> The "innerReturn" value is certainly there in the BlockContext
> nonLocalReturn handling, its just not available to me.

> Anyone thought about this at all?
> =================================================================
> Dennis Smith, MaSc  --  Cherniak Software Development Corporation
> 400-10 Commerce Valley Dr E, Thornhill ON Canada  L3T 7N7
> Phone: 905.771.7011      FAX: 905.771.6288




Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks

Quote:

>In VisualAge Smalltalk it already works this way (i.e. exactly the way you
>want.).  This is a fairly  common requirement however I don't believe the
>other VMs do it.

Great -- in that case, I will just implement it ---

OK VW Dev-group, lets get with it and add this one,
        Eliot? James?

Quote:

>Try this in a workspace.

>[
> ^ true
>] ensure: [ :result |
>  result == true ifTrue: [Transcript cr; show: 'true returned' ].
>  result == false ifTrue: [Transcript cr; show: 'false returned' ].
>]

>[
> ^ false
>] ensure: [ :result |
>  result == true ifTrue: [Transcript cr; show: 'true returned' ].
>  result == false ifTrue: [Transcript cr; show: 'false returned' ]
>]

>of course, the contents of your block can have any non local return (unlike
>my simple example) including a block passed in with a return in it. Note
>that in your example below, if aBlock actually has a return statement, you
>will never assign to the ret variable because of the non-local return.

>/J



>> I will probably get taken to task by the experts for even asking
>> this, but here goes.

>> If I create a method like this

>> runBlock: aBlock
>> [
>> ret := aBlock value
>> ] ensure: [... do my clean up ...]
>> ^ret

>> AND if "aBlock" contains a return which is important,
>> I cannot tell what it is in my ensure: block.

>> Consider the following invocation

>> myMethod
>> self runBlock: [
>> doAction ifFalse: [^false].
>> doAnotherAction ifTrue: [^true].
>> doAnotherOne
>> ].
>> ^true

>> The cleanup action in my ensure: block wants to do something different
>> based on a false vs true return.  The specific case is wrapping code
>> in a database transaction (Gemstone to be exact, but the code is
>> on the client).  If I get false I want to abort if true commit.

>> I KNOW I can do this by putting the actions in another method an
>> saying

>> myMethod
>> ^self runBlock: [self doAllActions]

>> but in the simple cases it sure is easier to read the code when its
>> all there in front of you.

>> The "innerReturn" value is certainly there in the BlockContext
>> nonLocalReturn handling, its just not available to me.

>> Anyone thought about this at all?
>> =================================================================
>> Dennis Smith, MaSc  --  Cherniak Software Development Corporation
>> 400-10 Commerce Valley Dr E, Thornhill ON Canada  L3T 7N7
>> Phone: 905.771.7011      FAX: 905.771.6288


=================================================================
Dennis Smith, MaSc  --  Cherniak Software Development Corporation
400-10 Commerce Valley Dr E, Thornhill ON Canada  L3T 7N7
Phone: 905.771.7011      FAX: 905.771.6288



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
Jay,

Quote:
>[
> ^ true
>] ensure: [ :result |
>  result == true ifTrue: [Transcript cr; show: 'true returned' ].
>  result == false ifTrue: [Transcript cr; show: 'false returned' ].
>]

Time for some refactoring

1) Format (Full Metal Beck!)

[^true] ensure:
        [:result |
  result == true ifTrue:
                [Transcript
                        cr;
                        show: 'true returned'].
  result == false ifTrue:
                [Transcript
                        cr;
                        show: 'false returned']]

2) Remove unneeded testing of boolean

[^true] ensure:
        [:result |
  result ifTrue:
                [Transcript
                        cr;
                        show: 'true returned'].
  result ifFalse:
                [Transcript
                        cr;
                        show: 'false returned']]

3) Remove redundant boolean tests

[^true] ensure:
        [:result |
  result
                ifTrue:
                        [Transcript
                                cr;
                                show: 'true returned'].
                ifFalse:
                        [Transcript
                                cr;
                                show: 'false returned']]

4) Remove need to test result at all!
[^true] ensure:
        [:result |
        Transcript
                        cr;
                        show: result printString;
                        show: ' returned'].

                                And So It Goes
                                     Sames

============================================================================
Samuel S. Shuster
Continuum Methods & Frameworks, Inc.
Go Smalltalk!



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
On Fri, 17 Mar 2000 13:04:30 -0500, Samuel S. Shuster

Quote:

>Jay,

>>[
>> ^ true
>>] ensure: [ :result |
>>  result == true ifTrue: [Transcript cr; show: 'true returned' ].
>>  result == false ifTrue: [Transcript cr; show: 'false returned' ].
>>]

>Time for some refactoring

Gee Wiz -- your as bad as my boss, take an example used to
illustrate some general point and mess it up because
"it wouldn't occur in a business situation in exactly that
way"  :-)

Suppose the initial block said

[
        self thing == 0 ifTrue: [^false].
        self otherThing == 0 ifTrue: [^false].
        ^true
]: ensure... ???

I see though that you kept the parameter'ed version of
ensure: [:parm...] which was what the original question.

What is your position on adding an optional parameter
to the ensure block?

Quote:

>1) Format (Full Metal Beck!)

>[^true] ensure:
>    [:result |
>  result == true ifTrue:
>            [Transcript
>                    cr;
>                    show: 'true returned'].
>  result == false ifTrue:
>            [Transcript
>                    cr;
>                    show: 'false returned']]

>2) Remove unneeded testing of boolean

>[^true] ensure:
>    [:result |
>  result ifTrue:
>            [Transcript
>                    cr;
>                    show: 'true returned'].
>  result ifFalse:
>            [Transcript
>                    cr;
>                    show: 'false returned']]

>3) Remove redundant boolean tests

>[^true] ensure:
>    [:result |
>  result
>            ifTrue:
>                    [Transcript
>                            cr;
>                            show: 'true returned'].
>            ifFalse:
>                    [Transcript
>                            cr;
>                            show: 'false returned']]

>4) Remove need to test result at all!
>[^true] ensure:
>    [:result |
>    Transcript
>                    cr;
>                    show: result printString;
>                    show: ' returned'].

>                                And So It Goes
>                                     Sames

>============================================================================
>Samuel S. Shuster
>Continuum Methods & Frameworks, Inc.
>Go Smalltalk!



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
Sam,

Thanks for your refactoring efforts

The reason in the example to test explicitly is demontrate clearly to the
original poster how he could handle true, false and other. The key here  is
"other" return types.

So, if you want to experiment and change it to see the non boolean case ...

[
    ^ 0
] ensure: [ :result |
    result == true ifTrue: [Transcript cr; show: 'true returned' ].
    result == false ifTrue: [Transcript cr; show: 'false returned' ].
]

your first two refactoring attempts would cause walkbacks . The last will
still work, however the point was not to print a string with true or false,
the point was to demonstrate how you could check the return from an ensure:
block (in VA/Smalltalk) otherwise you would have refactored it right down
into "Transcript cr; show: 'true returned' " and really impressed us :-)

As an aside, one of the scariest modifications you could make is changing
someone elses code "x == true" ifTrue: [ ] into the x ifTrue: []  because of
the possibility it is a non-boolean.  Don't do this without completely
understanding why its there in the first place. This happens often in code
where new inst vars are being added and the code is expected to mutate
during a load (ENVY/Developer loading new code into a development image).

and just in case you're wondering, I obviously don't write code with x ==
true as a general rule :-)

Cheers,
/J

Quote:

>Jay,

>>[
>> ^ true
>>] ensure: [ :result |
>>  result == true ifTrue: [Transcript cr; show: 'true returned' ].
>>  result == false ifTrue: [Transcript cr; show: 'false returned' ].
>>]

>Time for some refactoring

>1) Format (Full Metal Beck!)

>[^true] ensure:
> [:result |
>  result == true ifTrue:
> [Transcript
> cr;
> show: 'true returned'].
>  result == false ifTrue:
> [Transcript
> cr;
> show: 'false returned']]

>2) Remove unneeded testing of boolean

>[^true] ensure:
> [:result |
>  result ifTrue:
> [Transcript
> cr;
> show: 'true returned'].
>  result ifFalse:
> [Transcript
> cr;
> show: 'false returned']]

>3) Remove redundant boolean tests

>[^true] ensure:
> [:result |
>  result
> ifTrue:
> [Transcript
> cr;
> show: 'true returned'].
>  ifFalse:
> [Transcript
> cr;
> show: 'false returned']]

>4) Remove need to test result at all!
>[^true] ensure:
> [:result |
>  Transcript
> cr;
> show: result printString;
> show: ' returned'].

>                                And So It Goes
>                                     Sames

>===========================================================================
=
>Samuel S. Shuster
>Continuum Methods & Frameworks, Inc.
>Go Smalltalk!



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
Jay,

Quote:
>your first two refactoring attempts would cause walkbacks .

Not in the code as provided. I refactored the code provided, not some imaginary
other code not in evidence. I would have refactored other code in another way.
It's easy to take issue with "What If," I was dealing with "What Is."

Quote:
>As an aside, one of the scariest modifications you could make is changing
>someone elses code "x == true" ifTrue: [ ] into the x ifTrue: []  because of
>the possibility it is a non-boolean.  

In the code provided, the scariest thing I can think of is NOT changing it! In
the code provided, the 'true' is most assuredly boolean. Indeed, there are
hundreds of reasons not to do change the code as you suggest, its just that
exactly none of them apply to the code as provided!

Of course, if the code changes in the future, so should the refactoring. But why
waste time today on what may or may not happen in the future? I'm certainly
psychotic, but I'm not psychic, nor have I ever met anyone who had the ability
to accurately divine what is needed in the future.

I stand by my refactorings.

                                And So It Goes
                                     Sames

============================================================================
Samuel S. Shuster
Continuum Methods & Frameworks, Inc.
Go Smalltalk!



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
Dennis,

Quote:
>[
>    self thing == 0 ifTrue: [^false].
>    self otherThing == 0 ifTrue: [^false].
>    ^true
>]: ensure... ???

1) Full Metal Beck

[self thing == 0 ifTrue: [^false].
self otherThing == 0 ifTrue: [^false].
^true] ensure: ["... ???"]

2) Two tests return same result... combine

[(self thing == 0 or: [self otherThing == 0]) ifTrue: [^false].
^true] ensure: ["... ???"]

3) Strict true/false "ifxxx" with one answering non computed Boolean results,
get rid of the guard clause ifxxx:

[^(self thing == 0 or: [self otherThing == 0]) not] ensure: ["... ???"]

Quote:
>I see though that you kept the parameter'ed version of
>ensure: [:parm...] which was what the original question.

>What is your position on adding an optional parameter
>to the ensure block?

It may have its use so why not. However, I don't think that the operated on
block should have an out of scope return, rather the #ensure: block should get
the result of the others answer... thus:

[(self thing == 0 or: [self otherThing == 0]) not] ensure: ["... ???"]

(Note absence of "^")

Finally, the result of the whole statement should be the last known answer of
the operated on block. Thus, if there is an error, it should answer it.

But that's my opinion, I could be wrong.

                                And So It Goes
                                     Sames

============================================================================
Samuel S. Shuster
Continuum Methods & Frameworks, Inc.
Go Smalltalk!



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
On Tue, 21 Mar 2000 17:45:00 -0500, Samuel S. Shuster

Quote:

>Dennis,

>>[
>>        self thing == 0 ifTrue: [^false].
>>        self otherThing == 0 ifTrue: [^false].
>>        ^true
>>]: ensure... ???

>1) Full Metal Beck

>[self thing == 0 ifTrue: [^false].
>self otherThing == 0 ifTrue: [^false].
>^true] ensure: ["... ???"]

>2) Two tests return same result... combine

>[(self thing == 0 or: [self otherThing == 0]) ifTrue: [^false].
>^true] ensure: ["... ???"]

>3) Strict true/false "ifxxx" with one answering non computed Boolean results,
>get rid of the guard clause ifxxx:

>[^(self thing == 0 or: [self otherThing == 0]) not] ensure: ["... ???"]

>>I see though that you kept the parameter'ed version of
>>ensure: [:parm...] which was what the original question.

>>What is your position on adding an optional parameter
>>to the ensure block?

>It may have its use so why not. However, I don't think that the operated on
>block should have an out of scope return, rather the #ensure: block should get
>the result of the others answer... thus:

>[(self thing == 0 or: [self otherThing == 0]) not] ensure: ["... ???"]

>(Note absence of "^")

>Finally, the result of the whole statement should be the last known answer of
>the operated on block. Thus, if there is an error, it should answer it.

>But that's my opinion, I could be wrong.

I agree with in almost all cases, and I try and code that way.
However, there are cases where things beome overly complicated
and unreadable when you do that, "Beck" not-withstanding.

For example, if there are 3 things to do and all three are
similar in nature and all three might fail, and assuming you
are not using exception handling to trap the failures, I think
it is much clearer to say

     [
        self action1 ifFalse: [^false].
        (self action2: aValue) ifFalse: [^false].
        self action3 ifFalse: [^false].
        true
    ] ensure...

If you do things like

        (self action1 or: [self action2: aValue])
                or: [self action3]

and particularaly if you have to use more than one line, it
becomes difficult to read, and it "feels" like the actions
are somehow inter-related rather than just
sequential steps.

I would also agree that if one went much more than 3 (maybe 4)
actions like that one might want to refactor.  I have found
that in our cases 2 or 3 are the norm.

It might be something like

        after adding an order
                - add a log record
                - add the order to a "pending order queue"

these kinds of pairs (sometimes 3's) are repeated many many times
(in slightly different forms)

Quote:

>                                And So It Goes
>                                     Sames

>============================================================================
>Samuel S. Shuster
>Continuum Methods & Frameworks, Inc.
>Go Smalltalk!

=================================================================
Dennis Smith, MaSc  --  Cherniak Software Development Corporation
400-10 Commerce Valley Dr E, Thornhill ON Canada  L3T 7N7
Phone: 905.771.7011      FAX: 905.771.6288



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
Dennis,

Quote:
>and particularaly if you have to use more than one line, it
>becomes difficult to read, and it "feels" like the actions
>are somehow inter-related rather than just
>sequential steps.

Well, I know what #or: and #and: do, so that doesn't occur to me that they can
be anything except sequential steps, which must also be somehow inter-related
because of the context in which they are called. If in fact they are not
inter-related, then the whole batch of code should be thrown out and one should
start over.

Say It Once. Two or Three times, is One or Two times too much.

                                And So It Goes
                                     Sames

============================================================================
Samuel S. Shuster
Continuum Methods & Frameworks, Inc.
Go Smalltalk!



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks
On Wed, 22 Mar 2000 19:04:00 -0500, Samuel S. Shuster

Quote:

>Dennis,

>>and particularaly if you have to use more than one line, it
>>becomes difficult to read, and it "feels" like the actions
>>are somehow inter-related rather than just
>>sequential steps.

>Well, I know what #or: and #and: do, so that doesn't occur to me that they can
>be anything except sequential steps, which must also be somehow inter-related
>because of the context in which they are called. If in fact they are not
>inter-related, then the whole batch of code should be thrown out and one should
>start over.

OK, you've been at it longer than I, and I do use and:/or: quite a bit
more than I did a few years ago when I started, so perhaps in another
year or two I will fully agree (sorry if that sounds a bit sarcastic,
that was not the intent).  

Quote:

>Say It Once. Two or Three times, is One or Two times too much.

>                                And So It Goes
>                                     Sames

>============================================================================
>Samuel S. Shuster
>Continuum Methods & Frameworks, Inc.
>Go Smalltalk!

=================================================================
Dennis Smith, MaSc  --  Cherniak Software Development Corporation
400-10 Commerce Valley Dr E, Thornhill ON Canada  L3T 7N7
Phone: 905.771.7011      FAX: 905.771.6288



Wed, 18 Jun 1902 08:00:00 GMT  
 question on return from blocks and ensure: blocks

Quote:

> On Wed, 22 Mar 2000 19:04:00 -0500, Samuel S. Shuster

> >Dennis,

> >>and particularaly if you have to use more than one line, it
> >>becomes difficult to read, and it "feels" like the actions
> >>are somehow inter-related rather than just
> >>sequential steps.

> >Well, I know what #or: and #and: do, so that doesn't occur to me that they can
> >be anything except sequential steps, which must also be somehow inter-related
> >because of the context in which they are called. If in fact they are not
> >inter-related, then the whole batch of code should be thrown out and one should
> >start over.

> OK, you've been at it longer than I, and I do use and:/or: quite a bit
> more than I did a few years ago when I started, so perhaps in another
> year or two I will fully agree (sorry if that sounds a bit sarcastic,
> that was not the intent).  

Hrm.  I really dislike using and: and or: as a guard to decide whether
to continue forward.  and means *and*, a computation on booleans.  It
just doesn't sound like a control flow structure.

If you want to have this style of guard, how about using ifTrue: and
ifFalse:, instead ?

        (action 1) ifTrue: [
                action 2 ifTrue: [
                        action 3 ] ]

Or better yet, use early returns from a method?

        action 1 ifFalse: [ ^self ].
        action 2 ifFalse: [ ^self ].
        action 3.

Lex



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. std blocks vs blocks+cache ( was: block behavior)

2. Technical question (blocking/non-blocking)

3. ensure block not being executed

4. ERROR "Corrupt Block/Unknown Block Freed"

5. Corrupt block/unknown block type freed bug

6. 0 BLOCK in Gforth (Was: Blocks Help etc.)

7. blocks and lambdas, or blocks as first-class entities

8. Associating block to block call?

9. Block passing: obj.new(){block}

10. blocking and non-blocking assignment

11. Strange behaviour with blocking and non-blocking assignment

12. blocking/non-blocking

 

 
Powered by phpBB® Forum Software