Skip Menu |
 

This queue is for tickets about the MooseX-Declare CPAN distribution.

Report information
The Basics
Id: 43186
Status: open
Priority: 0/
Queue: MooseX-Declare

People
Owner: Nobody in particular
Requestors: yanick+cpan [...] babyl.dyndns.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: pitfalls/tricky parts to mention in the pod
Download (untitled) / with headers
text/plain 1.4k
Playing with MooseX::Declare I've come across two points that are not really bugs, but gotchas of the way M::D is implemented. I think it may be a good idea to address those issues in the pod, so that the caveat can emptor with all the information in his or her possession. 1. lexical variables within a class { } or role { } don't work. E.g., the following example will fail: use MooseX::Declare; class Foo { my $i; sub bar { ++$i; } } package main; my $foo = Foo->new; print $foo->bar; I can't say I understand all the nitty gritty details of the dark, dark black magic used by M::D and Devel::Declare, but I think this is simply due to the exporting of the subs to the class' namespace, which indeed means that the final version of "bar" we'll be calling will not be in the proper context to see '$i' anymore. 2. CPAN package version This one is not a bug at all, but more of a general question of how we should play nicely with CPAN, which of course doesn't understand what 'class' means. The best way I've found so far is to add a little header to the file: { package Language::l33t::Operators; # hi, CPAN, we're here! our $VERSION = "0.03"; } use MooseX::Declare; role Language::l33t::Operators { .... Assuming that I'm not off the mark with my description of the problems and my fix for #2, I can come up with a pod patch if you so desire. PS: and, as always, thanks for creating M::D in the first place. Very cool module. :-)
Download (untitled) / with headers
text/plain 358b
Greets, I've spent the last two nights with hacking pause to *really* not get in the way when authors provide a META.yaml with a provides field. The intention was already there for a long time but on Sunday it turned out to be buggy. Please try uploading with a META.yml or reindex if the META.yml with the provides field is already uploaded. (Hi Rafl!)
CC: yanick+cpan [...] babyl.dyndns.org
Subject: Re: [rt.cpan.org #43186] pitfalls/tricky parts to mention in the pod
Date: Thu, 12 Feb 2009 11:19:38 -0500
To: Andreas Koenig via RT <bug-MooseX-Declare [...] rt.cpan.org>
From: yanick [...] babyl.dyndns.org
Download (untitled) / with headers
text/plain 769b
Hi Andreas, Rafl, On Tue, Feb 10, 2009 at 04:56:36PM -0500, Andreas Koenig via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=43186 > > > I've spent the last two nights with hacking pause to *really* not get in > the way when authors provide a META.yaml with a provides field.
Excellent. This doesn't fix the whole issue, though, as either the META builder (in my case Module::Build) still has to figure out the version from the module files, or the META file has to be munged after the fact. The "{ package XXX; ... }" workaround I was mentioning in the bug description will work for that. Or that will as well: <<###; # for the META builder package Foo ### use MooseX::Declare; class Foo { our $VERSION = '1.2.3'; } Joy, `/anick --
Download (untitled) / with headers
text/plain 491b
On Tue Feb 10 16:56:36 2009, ANDK wrote: Show quoted text
> Greets, > > I've spent the last two nights with hacking pause to *really* > not get in the way when authors provide a META.yaml with a provides > field.
Nice. Therefore it finally also recognizes my Acme::Ünicöde in the way one would expect. If that isn't progress, what then? :-) Thanks. Steffen -- Steffen Schwigon <ss5@renormalist.net> Dresden Perl Mongers <http://dresden-pm.org/> Deutscher Perl-Workshop <http://www.perl-workshop.de/>
Download (untitled) / with headers
text/plain 1.1k
On Thu Feb 12 10:32:55 2009, yanick@babyl.dyndns.org wrote: Show quoted text
> Hi Andreas, Rafl, > > On Tue, Feb 10, 2009 at 04:56:36PM -0500, Andreas Koenig via RT wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=43186 > > > > > I've spent the last two nights with hacking pause to *really* not get in > > the way when authors provide a META.yaml with a provides field.
> > Excellent. This doesn't fix the whole issue, though, > as either the META builder (in my case Module::Build) still has > to figure out the version from the module files, or the META > file has to be munged after the fact. The "{ package XXX; ... }"
workaround Show quoted text
> I was mentioning in the bug description will work for that. Or > that will as well: > > <<###; # for the META builder > package Foo > ### > > use MooseX::Declare; > > class Foo { > our $VERSION = '1.2.3'; > } > > > Joy, > `/anick >
I've written a Module::Install plugin that attempts to address this issue without needing the developer to manually put package stanzas in the source files. http://search.cpan.org/perldoc?Module::Install::ProvidesClass rafl has just given me comaint on MX::Declare as well, so I will mention this module in the POD of the next release


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.