[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [FWP] awww, no fun :(



On Thu, Apr 12, 2001 at 10:02:06PM +0100, Michael G Schwern wrote:
> On Thu, Apr 12, 2001 at 10:47:55PM +0200, Abigail wrote:
> > Deprecating to me means, there's an advantage to remove it from the
> > language. I fail to see what the advantage would be. Do you have a better
> > of what 'sub foo {last}' could do? Would it make the implementation
> > faster?
> 
> This isn't about faster, its about action at a distance.  This feature
> doesn't have any use but for implementing action at a distance.  Its
> sort of like a reverse goto LABEL.
> 
> Basically, you're calling a subroutine that alters the control flow of
> its caller.  There's very, very, very few legit things that are
> allowed to do this in Perl.  One is goto LABEL and its dubious at
> best.  But at least goto has to go to a declared LABEL.  die() inside
> an eval BLOCK can sort of be seen to do something similar, but its
> obvious you're expecting it (since you used an eval BLOCK).  Finally,
> there's exit() which is not recommended to use in a subroutine or
> module.
> 
> 
> Essentially, consider the following...
> 
>         while(1) {
>             foo();
>         }
> 
> When will that exit normally (ie. not via a die or exit)?  This should
> be a simple answer, but you can't know without examining foo() and all
> routines foo() might call.  This is bad.

Ah, so I guess we should deprecate 

    while ($i) {
        foo();
    }

as well, because you don't know when that exits without examing foo.

And for that matter:

    while (foo ()) {}

needs an examination of foo() too.

> All of the above (exit, die... maybe goto) have reasons for causing
> this caveat.  last() really doesn't.  *especially* because it can act
> without a LABEL.
> 
> 
> Its simple enough to get around.  Simply set a global flag...

Oh, global variables. Sorry, but replacing one can of worms with
another isn't worth the trouble in my opinion.

>         sub foo { $Exit_Loop = 1 }
> 
>         while (1) { 
>             foo();
>             last if $Exit_Loop;
>         }
> 
> Now at least its clearer how loop control will go.

Really? How would you know how $Exit_Loop gets set without examining foo?

Is "the loop exits if foo() set $Exit_Loop to the true value" that much
better than "the loop exits if foo() does a last"? They are both doing
action at a distance, it's just the syntactical sugar that's difference.

I don't think cane sugar is any better than sugar from beets.


If you want to forbid all these kinds of "action at a distance" and
have structured code, you should get rid of "last", "next" and "redo".
Then you only have to check your guard.


Abigail

==== Want to unsubscribe from Fun With Perl?  Well, if you insist...
==== Send email to <fwp-request@technofile.org> with message _body_
====   unsubscribe