On the dangers of too much debugging text

[redlemon]

I'm using Catalyst to build an application, and are using the Catalyst::Controller::BindLex module to keep the code more readeable:

    my $value :Stashed = 1;

in stead of

    $c->stash( value => 1 );

This is all great stuff until you have:

    sub action
         : Chained('other_action')
    {
        my $value: Stashed;
        #
        # a bit of code using $value
        #
        my $value: Stashed = 1;
    }

The last line was there in the initial iteration of the action, the first line got added after some redesign.

Catalyst server started up as usual with a summary of actions, paths, plugins, and a lot of my own debug prints. The first notice something was wrong was when I got:

    panic: Can't find SCALAR(0x3240d90) in the the caller's lexical pa
+d

This sent me on a merry chase through all the internals using the debugger. Somehow BindLex saw a different address for $value than the one I saw in the debugger. After a couple of hours, lots of coffee, and some silly experiments I decided to take a shower and go to bed. It was after 5AM after all....

Somewhere between shower and bed it dawned on me. The reason BindLex was seeing a different address must be because there were 2 vars with the same name in the subroutine's scope!! So I went back and looked closely at the output of the server start again, and there it was, as the first line of output:

    "my" variable $value masks earlier declaration in same scope.

So, lessons learned:

• There's such a thing as too much debugging output
• There is some really clever magic going on in BindLex, Devel::Caller and PadWalker. Kudo's for the people who came up with that code.
• There is a point where focussing too much on a problem becomes counter-productive. Stop and go do something else and enlightenment follows.

--
Lyon

[perrin]

my $value :Stashed = 1; in stead of $c->stash( value => 1 );

Wow. Never in a million years would I have guessed those two lines were meant to do the same thing. I'm not seeing how this makes anything more readable.

[dragonchild]

I'm with perrin on this one. Having used BindLex on a project before, I think it makes using globals waaaay too easy. The problem is that the stash (and flash) are global variable repositories. They're useful, otherwise mst would've killed nothingmuch before he could've finished adding it. But, they're useful in the way that a Doberman is useful. You just don't let the Doberman have the run of the place. Stashed variables should be very obviously stashed variables. The easiest way to do this is to have the stashed variable be accessible only through the long function call. The point behind a lexical is that it's safe - whatever you throw into it won't leave the current scope. BindLex violates that guarantee.

I think this falls under the "rope enough to hang yourself with" part of Perl. But, I'm also crochety. Meh.

[zby]

Or one can also conclude that BindLex is evil. I mean - that was clearly your error - but if were not using BindLex you would have found it much faster.

[oko1]

> So I went back and looked closely at the output of the server start again, and
there it was, as the first line of output:

One of the earliest lessons I learned about Perl - and that I teach to my students these days - is "always look at the first reported error. Often, solving that one takes care of all or many of the subsequent ones."

[kyle]

I think of "my $value :Stashed = 1;" as being more like...

my $value = $c->stash->{value} = 1;

...except that $value remains an alias for $c->stash->{value} afterward.