# For example
    while (my $el = pop @els){
        # Body of loop
    }

# Is it equivelant to this?
{
    my $el = pop @els;
    {
        # Body of loop
        
    }

}

# Or this?

{
    my $el = pop @els;
        # Body of loop
}
[download]

...is the statement part of a conditional in the same block as the body itself?

No, the conditional is outside the block, both physically and logically (err...physiologically? ;-).

Your example is equivalent to:

    my $el;
    while ($el = pop @els) {
        # Body of loop
    }
[download]

BTW, in Perl 6, if and while (and the rest of the control structures) can be thought of as built-in functions. As if they were:

    sub while (BOOL $condition, &closure) {...}

    sub if (BOOL $condition, &closure) {...}
[download]

That's why the conditional is not part of the block: it's an entirely separate argument to the control structure.

And, yes, you'll be able to get the signature (a.k.a. prototype) of a control structure, and overload it, and redefine it (lexically).

And you'll probably be able to write bad things like:

    if condition(), &call_me;
[download]

and worse things like:

    &debug := { if BEGIN{$debug}, &^action };

    # and later...

    debug { print "here" }
[download]

Thanks for the enlightenment. Do you think there will be a mechanism to detect this? One thing I think would be nice would be able to tell if you are called in a control structure or not for lazy DWIM functions, like this findone { coderef } @array

-Lee

"To be civilized is to deny one's nature."

v-strings

I don't know if Larry has considered their disposition yet.

*whisper*Banish them... they were a terrible hack... develop a general purpose mechanism instead of this abomination...*whisper*

Perl's laissez faire approach to OO.

Staying in Perl 6. But being augmented by a second, B&D, OO mechanism.

BTW, those who are complaining are, for the most part, neither grinding axes nor bondage freaks. They are generally people with large commercial OO production systems to build, who would prefer not to have to jump through so many hoops to get compile-time checking, declarative attributes, pre- and post-conditions, strong encapsulation, etc. That is, they genuinely need all those valuable, scalable OO tools that Perl 5's laissez faire approach to OO trades off.

Personally, if I can use Perl's OO as I currently do I'll remain happy as a pig in mud.

I've built several large (some very large) commercial OO production systems and never found Perl's OO lacking in any significant way.

Well, sure. But not everyone is as smart, or as disciplined as you. And even if they were, many of them work in large programming teams with other people who certainly aren't as smart, or as disciplined as you.

Such people really appreciate tools (and whips and chains) that make life simpler.

Personally, if I can use Perl's OO as I currently do I'll remain happy as a pig in mud.

Then you'll be wallowing contentedly for many years to come.

On the other hand, I suspect that you'll also come to appreciate how much easier and quicker Perl 6 makes it to build classes. And that eventually you may even enjoy the whip of design-by-contract or the chain of proper encapsulation.

C'mon! You know you want to! ;-)

Gone in Perl 6. Replaced by methods on individual filehandles.

All (sniff) good things must come to a (sniff) end eh?

Ill miss those ones I tell yah. Its sad to see such friendly variables consigned to the waste basket of history... Sniff.

Globs

Gone in Perl 6. Every symbol has its own entry in some symbol table.

Thank you thank you! Ive been working on a new dumper module recently and those dang globs caused my code size to go up by about 30%.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.