[Catalyst] experiences using Catalyst::Controller::BindLex?

[Yuval Kogman]

On Mon, May 01, 2006 at 03:02:15 -0700, John Napiorkowski wrote:
> Hi,
> 
> I like to get some feedback from people using the
> Catalyst::Controller::BindLex module.  This module
> really seems added a lot to the appearence and ease of
> use in handling stashed and session info.  I see this
> being used all over the source code for Agave and it
> just really makes sense if I could use it as well.

Yay

> However I can see why it's not part of the core
> catalyst, since it is very difficult to install.
> 
> What I am asking is for people who are using this to
> give some comments about it's stability in production
> systems as well as if they just force installed some
> of the most troublesome modules, such as Devel::Caller
> (which appears to be broken for perl 5.8.1 and up if
> the notes in the tests are correct).

Hmm.. I usded Devel::Caller before writing BindLex, always with >
5.8.3 (since that's pretty much the first version of Perl I wrote
seriously with), so I don't think that's the case ;-)

Have you tried talking with Richard Clamp? I don't see a pattern
from the test failure reports on CPAN testers
(http://cpantesters.perl.org/show/Devel-Caller.html#Devel-Caller-0.09).

Admittedly these modules *do* explode, hence the large warning. =/

Have you considered an editor macro instead? It doesn't help with
code readability, but it does let you write faster.


> Makes me wish I understood enough about attributes to
> rewrite this using more modern and well supported
> modules.

The problem is not with the attributes, it's with:

	1. the fact that the attribute handler has to walk up the stack
	to look for $c. Although Devel::Caller::Perl also supports
	argument extraction, see point 4.

	2. the fact that aliasing is not well supported in the sense
	that you need to do it with optional modules (Data::Alias, or
	Array::RefElem and Devel::LexAlias which I used)

	3. Lexical pads must be walked using PadWalker, as they are also
	not exposed by Perl itself.

	4. To use PadWalker to open up a lexical pad we need that
	subroutine's code reference, which is a feature that only
	Devel::Caller provides (hence not using Devel::Caller::Perl).

The following features are implemented with corresponding magic. If
you like to give some of the features up I will be happy to help you
implement an easier to install alternative to BindLex:

	attribute syntax - no magic at all - when the variable
	allocation is ready a method on the current package is
	called, with the reference to the subroutine and all the
	attributes that were collected

	no need to specify $c - This is implemented by _get_c_obj, which
	walks up the stack.

	no need to specify variable name - this is implemented by
	_find_in_pad, which takes a reference and a call level and
	locate the subroutine in that lexical pad, and uses it's name
	(minus the symbol) for the pad entry

	aliasing semantics - the behavior that allows variables to be
	read/write consistently accross subs is implemented using
	Devel::LexAlias and Array::RefElem. This is implemented by
	_bind_lex which takes $c, the hash to bind to, a reference to
	the variable, and the hash key to store under.

Note that attributes cannot take "perlish" arguments - they only get
strings ( : Stashed($c) won't work ), so that's what part of the
fussing is about.

Ciao

-- 
  Yuval Kogman <nothingmuch at woobling.org>
http://nothingmuch.woobling.org  0xEBD27418

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060501/cfdfa359/attachment.pgp