Skip Menu |
 

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

Report information
The Basics
Id: 43773
Status: resolved
Priority: 0/
Queue: MooseX-Declare

People
Owner: Nobody in particular
Requestors: nelo.onyiah [...] gmail.com
Cc:
AdminCc:

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



Subject: Problems playing with MooseX::ClassAttribute
Download (untitled) / with headers
text/plain 1.1k
Hi, I noticed that the following use case will not compile: use MooseX::Declare; use MooseX::ClassAttribute; class MXDeclare with MooseX::Getopt { class_has ID => ( isa => 'Int', is => 'ro', default => sub { int rand 1000 }, ); has name => ( isa => 'Str', is => 'ro', required => 1, ); } However when I move the "use MooseX::ClassAttribute" into the class definition it works: use MooseX::Declare; class MXDeclare with MooseX::Getopt { use MooseX::ClassAttribute; # this works class_has ID => ( isa => 'Int', is => 'ro', default => sub { int rand 1000 }, ); has name => ( isa => 'Str', is => 'ro', required => 1, ); } I realize this is not really a bug, more like a feature request as it would not stop me from writing code wit this module. I just think it would be nice to keep all the imports in the same place and it may well point to something going on behind the scenes that you may or may not be aware of. I have attached the failing test and the example code. Thank you for a great module!
Subject: mxdeclare.t
Download mxdeclare.t
text/x-perl 102b
#!/usr/bin/env perl use strict; use warnings; use Test::More 'no_plan'; use_ok('MXDeclare') or exit;
Subject: MXDeclare.pm
Download MXDeclare.pm
text/x-perl 312b
use MooseX::Declare; use MooseX::ClassAttribute; class MXDeclare with MooseX::Getopt { class_has ID => ( isa => 'Int', is => 'ro', default => sub { int rand 1000 }, ); has name => ( isa => 'Str', is => 'ro', required => 1, ); }
Subject: Re: [rt.cpan.org #43773] Problems playing with MooseX::ClassAttribute
Date: Mon, 2 Mar 2009 17:52:44 +0100
To: "nelo.onyiah [...] gmail.com via RT" <bug-MooseX-Declare [...] rt.cpan.org>
From: Florian Ragwitz <rafl [...] debian.org>
Download (untitled) / with headers
text/plain 2.6k
Hi, thanks for your report! On Mon, Mar 02, 2009 at 10:55:58AM -0500, nelo.onyiah@gmail.com via RT wrote: Show quoted text
> I noticed that the following use case will not compile: > > use MooseX::Declare; > use MooseX::ClassAttribute; > class MXDeclare with MooseX::Getopt { > class_has ID => ( > isa => 'Int', > is => 'ro', > default => sub { int rand 1000 }, > ); > has name => ( > isa => 'Str', > is => 'ro', > required => 1, > ); > } > > However when I move the "use MooseX::ClassAttribute" into the class > definition it works: > > use MooseX::Declare; > class MXDeclare with MooseX::Getopt { > use MooseX::ClassAttribute; # this works > class_has ID => ( > isa => 'Int', > is => 'ro', > default => sub { int rand 1000 }, > ); > has name => ( > isa => 'Str', > is => 'ro', > required => 1, > ); > } > > I realize this is not really a bug, more like a feature request as it > would not stop me from writing code wit this module. I just think it > would be nice to keep all the imports in the same place and it may well > point to something going on behind the scenes that you may or may not be > aware of.
What actually happens when you're doing class Foo { ... } is something like { package Foo; use Moose; ... } So what your first example does is importing class_has into the main:: package and then trying to use it from another package, which isn't going to work. I can see why this can be confusing, but I'm afraid I can't change that. However, I'm planning on adding a new piece of syntax that will allow you to import symbols from somewhere else and have them automatically cleaned from your namespace at the end of compilation. That already happens for Moose and Moose::Role keywords, but wouldn't work for importing MooseX::ClassAttribute, unless you namespace::clean yourself afterwards. I think it'll look something like class Foo with Baz { using MooseX::ClassAttribute; using MooseX::Types::Structured qw(Tuple Dict); ... } That way it'd be easier to keep track of imports and having them all in the same place, per class. Would that count as fulfilling your feature request? Show quoted text
> I have attached the failing test and the example code.
Thanks. I don't think I will apply it tho, because it's unlikely that it will ever pass, for the above reasons. What I'd love to apply is a small change to the documentation, explaining why the first example you gave doesn't work and why the second one does. The git repository is at http://github.com/rafl/moosex-declare -- BOFH excuse #36: dynamic software linking table corrupted
Download signature.asc
application/pgp-signature 189b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #43773] Problems playing with MooseX::ClassAttribute
Date: Mon, 2 Mar 2009 20:24:10 +0000
To: bug-MooseX-Declare [...] rt.cpan.org
From: Ifejinelo Onyiah <nelo.onyiah [...] googlemail.com>
Download (untitled) / with headers
text/plain 3.7k
Thank you for your prompt response. I have provided a draft documentation which I hope meets your specification. Your plans for the new syntax looks great to me and certainly meets my feature request. In essence, only MooseX::Declare would get imported outside the class definition (as it needs to be) and everything else gets imported inside the class with the keyword "using": use MooseX::Declare; class Foo { use Data::Dumper 'Dumper'; # using Data::Dumper -- future syntax method dumper () { print Dumper @_ } } Perhaps I should put that in the docs :) 2009/3/2 Florian Ragwitz via RT <bug-MooseX-Declare@rt.cpan.org> Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=43773 > > > Hi, > > thanks for your report! > > > On Mon, Mar 02, 2009 at 10:55:58AM -0500, nelo.onyiah@gmail.com via RT > wrote:
> > I noticed that the following use case will not compile: > > > > use MooseX::Declare; > > use MooseX::ClassAttribute; > > class MXDeclare with MooseX::Getopt { > > class_has ID => ( > > isa => 'Int', > > is => 'ro', > > default => sub { int rand 1000 }, > > ); > > has name => ( > > isa => 'Str', > > is => 'ro', > > required => 1, > > ); > > } > > > > However when I move the "use MooseX::ClassAttribute" into the class > > definition it works: > > > > use MooseX::Declare; > > class MXDeclare with MooseX::Getopt { > > use MooseX::ClassAttribute; # this works > > class_has ID => ( > > isa => 'Int', > > is => 'ro', > > default => sub { int rand 1000 }, > > ); > > has name => ( > > isa => 'Str', > > is => 'ro', > > required => 1, > > ); > > } > > > > I realize this is not really a bug, more like a feature request as it > > would not stop me from writing code wit this module. I just think it > > would be nice to keep all the imports in the same place and it may well > > point to something going on behind the scenes that you may or may not be > > aware of.
> > What actually happens when you're doing class Foo { ... } is something like > > { > package Foo; > use Moose; > ... > } > > So what your first example does is importing class_has into the main:: > package and then trying to use it from another package, which isn't > going to work. > > I can see why this can be confusing, but I'm afraid I can't change that. > > However, I'm planning on adding a new piece of syntax that will allow > you to import symbols from somewhere else and have them automatically > cleaned from your namespace at the end of compilation. That already > happens for Moose and Moose::Role keywords, but wouldn't work for > importing MooseX::ClassAttribute, unless you namespace::clean yourself > afterwards. > > I think it'll look something like > > class Foo with Baz { > using MooseX::ClassAttribute; > using MooseX::Types::Structured qw(Tuple Dict); > ... > } > > That way it'd be easier to keep track of imports and having them all in > the same place, per class. > > Would that count as fulfilling your feature request? >
> > I have attached the failing test and the example code.
> > Thanks. I don't think I will apply it tho, because it's unlikely that it > will ever pass, for the above reasons. > > What I'd love to apply is a small change to the documentation, > explaining why the first example you gave doesn't work and why the > second one does. The git repository is at > http://github.com/rafl/moosex-declare > > > -- > BOFH excuse #36: > dynamic software linking table corrupted > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFJrA7bdC8qQo5jWl4RAuvQAJ0ehPMq9uwtX8+jUgeILp+OcXFc2gCfXqAn > K/cxD4GCWo3HzqBnyKGdn3Q= > =GwAs > -----END PGP SIGNATURE----- > >
-- Nelo Onyiah
Subject: Re: [rt.cpan.org #43773] Problems playing with MooseX::ClassAttribute
Date: Mon, 2 Mar 2009 22:05:31 +0100
To: Ifejinelo Onyiah via RT <bug-MooseX-Declare [...] rt.cpan.org>
From: Florian Ragwitz <rafl [...] debian.org>
Download (untitled) / with headers
text/plain 1.5k
On Mon, Mar 02, 2009 at 03:25:08PM -0500, Ifejinelo Onyiah via RT wrote: Show quoted text
> Thank you for your prompt response. I have provided a draft documentation > which I hope meets your specification. Your plans for the new syntax looks > great to me and certainly meets my feature request.
Cool, thanks for the input on this. I've reviewed your patch and it looks good to me. I'm planning on implementing the 'using' keyword today or tomorrow and will apply your patch as soon as I'm done. Show quoted text
> In essence, only MooseX::Declare would get imported outside the class > definition (as it needs to be) and everything else gets imported inside the > class with the keyword "using":
Exactly. Show quoted text
> use MooseX::Declare; > class Foo { > use Data::Dumper 'Dumper'; > # using Data::Dumper -- future > syntax > > method dumper () { print Dumper @_ } > }
Yes. 'using' is really just an alternative syntax for 'use', except it also cleans all imports automatically. Show quoted text
> Perhaps I should put that in the docs :)
I think it's a good example. It might also be good to choose an example where the import has the same name as a method, to illustrate how both can co-exist without a problem. class MyDumper { using Data::Dump qw/dump/; method dump ($value) { return dump($value) } # calls the imported dump with $value method pp ($value) { $self->dump($value) } # alias for the dump method } MyDumper->new->dump($some_value); MyDumper->new->pp($some_value); probably not a good example, but i believe it makes the point quite clear. -- BOFH excuse #90: Budget cuts
Download signature.asc
application/pgp-signature 189b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #43773] Problems playing with MooseX::ClassAttribute
Date: Tue, 3 Mar 2009 00:07:33 +0000
To: bug-MooseX-Declare [...] rt.cpan.org
From: Ifejinelo Onyiah <nelo.onyiah [...] googlemail.com>
Okay. I'll add those doc changes when you're finished with your "using_keyword" branch off github. 2009/3/2 Florian Ragwitz via RT <bug-MooseX-Declare@rt.cpan.org> Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=43773 > > > On Mon, Mar 02, 2009 at 03:25:08PM -0500, Ifejinelo Onyiah via RT wrote:
> > Thank you for your prompt response. I have provided a draft documentation > > which I hope meets your specification. Your plans for the new syntax
> looks
> > great to me and certainly meets my feature request.
> > Cool, thanks for the input on this. > > I've reviewed your patch and it looks good to me. I'm planning on > implementing the 'using' keyword today or tomorrow and will apply your > patch as soon as I'm done. >
> > In essence, only MooseX::Declare would get imported outside the class > > definition (as it needs to be) and everything else gets imported inside
> the
> > class with the keyword "using":
> > Exactly. >
> > use MooseX::Declare; > > class Foo { > > use Data::Dumper 'Dumper'; > > # using Data::Dumper -- future > > syntax > > > > method dumper () { print Dumper @_ } > > }
> > Yes. 'using' is really just an alternative syntax for 'use', except it > also cleans all imports automatically. >
> > Perhaps I should put that in the docs :)
> > I think it's a good example. It might also be good to choose an example > where the import has the same name as a method, to illustrate how both > can co-exist without a problem. > > class MyDumper { > using Data::Dump qw/dump/; > method dump ($value) { return dump($value) } # calls the imported dump > with $value > method pp ($value) { $self->dump($value) } # alias for the dump method > } > > MyDumper->new->dump($some_value); > MyDumper->new->pp($some_value); > > > probably not a good example, but i believe it makes the point quite > clear. > > > -- > BOFH excuse #90: > Budget cuts > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFJrEoadC8qQo5jWl4RAh5EAJ9/y2ndp3V15fM1jvzYdeci+ISwlACcDO79 > aEOR8Ot+GOSdBiFfwrg/G90= > =7dT6 > -----END PGP SIGNATURE----- > >
-- Nelo Onyiah
Subject: Re: [rt.cpan.org #43773] Problems playing with MooseX::ClassAttribute
Date: Tue, 3 Mar 2009 01:11:50 +0100
To: Ifejinelo Onyiah via RT <bug-MooseX-Declare [...] rt.cpan.org>
From: Florian Ragwitz <rafl [...] debian.org>
Download (untitled) / with headers
text/plain 430b
On Mon, Mar 02, 2009 at 07:07:46PM -0500, Ifejinelo Onyiah via RT wrote: Show quoted text
> Okay. I'll add those doc changes
Awesome, thanks! Show quoted text
> when you're finished with your "using_keyword" branch off github.
which I just did, although with a slightly different result than I initially expected. See the commit messages and the message I just sent you on github. Sorry for the inconvenience. -- BOFH excuse #253: We've run out of licenses
Download signature.asc
application/pgp-signature 189b

Message body not shown because it is not plain text.



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.