MadMongers

On Thu, 9 Feb 2012 13:21:37 -0600
Rob Hoelz  wrote:

> On Thu, 09 Feb 2012 11:46:41 -0600
>  wrote:
>
> > mcholste wrote:
> > Thanks all, for your responses!  None of you were helpful.  ;)
> >
> > > david-delikat wrote:
> > > package plugin;
> > > my $data;
> > > sub getvar { \$data }
> > > $class = 'plugin';
> > > my $rdata = $class->getvar();
> >
> > This is close, but Moose prevents this from working elegantly.
> > Here's the whole story:
> >
> > package Plugins::MyPackage;
> > use Moose;
> > our $Description = "this my package";
> > has 'description' => (is => 'rw', isa => 'Str', required => 1,
> > default => $Description);
> >
> > package MyObj;
> > use Moose;
> > use Module::Pluggable require => 1, search_path => qw(Plugins);
> > sub BUILD {
> >  foreach my $plugin ($self->plugins()){
> >    print $plugin->description;
> >  }
> > }
> >
> > This fails in Moose because the object has not yet been
> > instantiated. It will spit:
> > Can't use string ("Plugins::MyPackage") as a HASH ref while "strict
> > refs" in use at accessor Plugins::MyPackage::description
> >
> > The easy solution is to just use a very simple sub as Dave
> > suggested:
> >
> > sub description { return $Description }
> >
> > This works great, but it really irks me that I have to do it this
> > way because it doesn't fit into the "Moose world" well of
> > inheritance, etc.  That's why I tried to do it just accessing the
> > package variable directly:
> >
> > sub BUILD {
> >  foreach my $plugin ($self->plugins()){
> >    print "$plugin::Description";
> >  }
> > }
> >
> > which also saves on creating the method at all.  This doesn't work
> > though, and was the cause of my email.  So, is there anything better
> > than a simple subroutine wrapper around the package variable?
> >
> > View Online
> >
> > Madison Area Perl Mongers - MadMongers
> > http://www.madmongers.org
>
> You could use symbolic references:
>
>   no strict 'refs';
>   my $description = ${$plugin . '::Description'};
>
> which is unclean.  Or you could use symbol tables:
>
>   my $description = ${ *{ $main::{$plugin .
> '::'}{'Description'} }{'SCALAR'} };
>
> which is ugly.
>
> -Rob

I should probably follow up by saying that I feel that using a simple
subroutine to return the description is the cleanest; however, if you
are absolutely set on setting the description in $Description, you
should put the symbolic reference/symbol table code in a method that
goes into a superclass or role that all of your plugins will be
extending/consuming.

JT is right, I should've included the long example to begin with, but
I did get a lot of good responses about general stuff!

I think Rob's symbol table is probably the cleanest way from a Perl
standpoint, but it kind of defeats the Moose purpose as well.  So, I
think I'll stick with the basic non-Moose-ified description
subroutine, unless anyone knows a way to have Moose do stuff on
packages before the packages are instantiated into objects.
Essentially, I just want to have the base class specify that all child
classes have a "description" method, but that won't work if the child
classes don't use Moose to define the accessor sub.

On Thu, Feb 9, 2012 at 1:29 PM,   wrote:
> hoelzro wrote:
>
> On Thu, 9 Feb 2012 13:21:37 -0600
> Rob Hoelz  wrote:
>
>
>> On Thu, 09 Feb 2012 11:46:41 -0600
>>  wrote:
>>
>> > mcholste wrote:
>> > Thanks all, for your responses!  None of you were helpful.  ;)
>> >
>> > > david-delikat wrote:
>> > > package plugin;
>> > > my $data;
>> > > sub getvar { \$data }
>> > > $class = 'plugin';
>> > > my $rdata = $class->getvar();
>> >
>> > This is close, but Moose prevents this from working elegantly.
>> > Here's the whole story:
>> >
>> > package Plugins::MyPackage;
>> > use Moose;
>> > our $Description = "this my package";
>> > has 'description' => (is => 'rw', isa => 'Str', required => 1,
>> > default => $Description);
>> >
>> > package MyObj;
>> > use Moose;
>> > use Module::Pluggable require => 1, search_path => qw(Plugins);
>> > sub BUILD {
>> >  foreach my $plugin ($self->plugins()){
>> >    print $plugin->description;
>> >  }
>> > }
>> >
>> > This fails in Moose because the object has not yet been
>> > instantiated. It will spit:
>> > Can't use string ("Plugins::MyPackage") as a HASH ref while "strict
>> > refs" in use at accessor Plugins::MyPackage::description
>> >
>> > The easy solution is to just use a very simple sub as Dave
>> > suggested:
>> >
>> > sub description { return $Description }
>> >
>> > This works great, but it really irks me that I have to do it this
>> > way because it doesn't fit into the "Moose world" well of
>> > inheritance, etc.  That's why I tried to do it just accessing the
>> > package variable directly:
>> >
>> > sub BUILD {
>> >  foreach my $plugin ($self->plugins()){
>> >    print "$plugin::Description";
>> >  }
>> > }
>> >
>> > which also saves on creating the method at all.  This doesn't work
>> > though, and was the cause of my email.  So, is there anything better
>> > than a simple subroutine wrapper around the package variable?
>> >
>> > View Online
>> >
>> > Madison Area Perl Mongers - MadMongers
>> > http://www.madmongers.org
>>
>> You could use symbolic references:
>>
>>   no strict 'refs';
>>   my $description = ${$plugin . '::Description'};
>>
>> which is unclean.  Or you could use symbol tables:
>>
>>   my $description = ${ *{ $main::{$plugin .
>> '::'}{'Description'} }{'SCALAR'} };
>>
>> which is ugly.
>>
>> -Rob
>
> I should probably follow up by saying that I feel that using a simple
> subroutine to return the description is the cleanest; however, if you
> are absolutely set on setting the description in $Description, you
> should put the symbolic reference/symbol table code in a method that
> goes into a superclass or role that all of your plugins will be
> extending/consuming.
>
> View Online
>
>
>
> Madison Area Perl Mongers - MadMongers
> http://www.madmongers.org

On Thu, 09 Feb 2012 13:53:38 -0600
wrote:

> mcholste wrote:
> JT is right, I should've included the long example to begin with, but
> I did get a lot of good responses about general stuff!
>
> I think Rob's symbol table is probably the cleanest way from a Perl
> standpoint, but it kind of defeats the Moose purpose as well.  So, I
> think I'll stick with the basic non-Moose-ified description
> subroutine, unless anyone knows a way to have Moose do stuff on
> packages before the packages are instantiated into objects.
> Essentially, I just want to have the base class specify that all child
> classes have a "description" method, but that won't work if the child
> classes don't use Moose to define the accessor sub.
>

When you say "child classes", do you mean "plugin classes"? If so, why
not force them to use Moose, and make them consume a role that requires
a description subroutine?  Also, you might find this interesting:

https://metacpan.org/module/MooseX::ClassAttribute

-Rob

> When you say "child classes", do you mean "plugin classes"? If so, why
> not force them to use Moose, and make them consume a role that requires
> a description subroutine?

They are technically child plugin classes.  There is a root plugin
class which defines what it takes to be a plugin.  They all use Moose,
and I could have them use a role which requires a description
subroutine, but I don't want to instantiate plugins when I check their
description, because I may not have all of the things I need to build
them at the time I want to check their description.

> Also, you might find this interesting:
>
> https://metacpan.org/module/MooseX::ClassAttribute

Very close to what I want, but has this important caveat:

"All features should just work. The one exception is the "required"
flag, which is not allowed for class attributes."  Since the whole
idea of inheritance was to dictate the child classes incorporated
certain attributes, that doesn't really get me much further.

Anyway, thanks for the info.

On Thu, 09 Feb 2012 16:52:58 -0600
wrote:

> mcholste wrote:
> > When you say "child classes", do you mean "plugin classes"? If so,
> > why not force them to use Moose, and make them consume a role that
> > requires a description subroutine?
>
> They are technically child plugin classes.  There is a root plugin
> class which defines what it takes to be a plugin.  They all use Moose,
> and I could have them use a role which requires a description
> subroutine, but I don't want to instantiate plugins when I check their
> description, because I may not have all of the things I need to build
> them at the time I want to check their description.
>
> > Also, you might find this interesting:
> >
> > https://metacpan.org/module/MooseX::ClassAttribute
>
> Very close to what I want, but has this important caveat:
>
> "All features should just work. The one exception is the "required"
> flag, which is not allowed for class attributes."  Since the whole
> idea of inheritance was to dictate the child classes incorporated
> certain attributes, that doesn't really get me much further.
>
> Anyway, thanks for the info.
>
> View Online
>
> Madison Area Perl Mongers - MadMongers
> http://www.madmongers.org

Would it be sufficient to check if description() were implemented as an
attribute or as a regular method?

----- Original Message -----

From: mcholste@gmail.com

To: admin@wisbin.com

Sent: Thursday, February 09, 2012 8:35 PM

Subject: [MadTalk] Re: Dynamically including package variable

mcholste wrote:

Nope, because I actually need the value back when it is a class var.  No worries, the plain 'ol sub is working ok.  I was just seeing if I were missing a better way of doing things with Moose, and the MooseX::Classattribute is really close.

On Thursday, February 9, 2012,  <rob@hoelz.ro> wrote:
> hoelzro wrote:
>
> On Thu, 09 Feb 2012 16:52:58 -0600
> wrote:
>
>> mcholste wrote:
>> > When you say "child classes", do you mean "plugin classes"? If so,
>> > why not force them to use Moose, and make them consume a role that
>> > requires a description subroutine?
>>
>> They are technically child plugin classes.  There is a root plugin
>> class which defines what it takes to be a plugin.  They all use Moose,
>> and I could have them use a role which requires a description
>> subroutine, but I don't want to instantiate plugins when I check their
>> description, because I may not have all of the things I need to build
>> them at the time I want to check their description.
>>
>> > Also, you might find this interesting:
>> >
>> > https://metacpan.org/module/MooseX::ClassAttribute
>>
>> Very close to what I want, but has this important caveat:
>>
>> "All features should just work. The one exception is the "required"
>> flag, which is not allowed for class attributes."  Since the whole
>> idea of inheritance was to dictate the child classes incorporated
>> certain attributes, that doesn't really get me much further.
>>
>> Anyway, thanks for the info.
>>
>> View Online
>>
>> Madison Area Perl Mongers - MadMongers
>> http://www.madmongers.org
>
> Would it be sufficient to check if description() were implemented as an
> attribute or as a regular method?
>
> View Online
>
> Madison Area Perl Mongers - MadMongers
> http://www.madmongers.org
>

View Online

Madison Area Perl Mongers - MadMongers
http://www.madmongers.org

The description is intended to be static.

Sorry for the "wild goose chase."  I left out details partially for
brevity but also because Perl has so many ways to do things, I wanted
to know what all of the other possibilities were.  I hope no one took
my "unhelpful" comment seriously--I was joking.

On Thu, Feb 9, 2012 at 9:25 PM,   wrote:
> esayward wrote:
>
> so what you're saying is, you had it working, but wanted to do it with
> moose? hmm.. and not giving us all the data for a decent response you
> basically sent us all on a wild goose chase? interesting... I tend to use
> the kiss method..
>
> ----- Original Message -----
> From: mcholste@gmail.com
> To: admin@wisbin.com
> Sent: Thursday, February 09, 2012 8:35 PM
> Subject: [MadTalk] Re: Dynamically including package variable
>
> mcholste wrote:
>
> Nope, because I actually need the value back when it is a class var.  No
> worries, the plain 'ol sub is working ok.  I was just seeing if I were
> missing a better way of doing things with Moose, and the
> MooseX::Classattribute is really close.
>
> On Thursday, February 9, 2012,   wrote:
>> hoelzro wrote:
>>
>> On Thu, 09 Feb 2012 16:52:58 -0600
>> wrote:
>>
>>> mcholste wrote:
>>> > When you say "child classes", do you mean "plugin classes"? If so,
>>> > why not force them to use Moose, and make them consume a role that
>>> > requires a description subroutine?
>>>
>>> They are technically child plugin classes.  There is a root plugin
>>> class which defines what it takes to be a plugin.  They all use Moose,
>>> and I could have them use a role which requires a description
>>> subroutine, but I don't want to instantiate plugins when I check their
>>> description, because I may not have all of the things I need to build
>>> them at the time I want to check their description.
>>>
>>> > Also, you might find this interesting:
>>> >
>>> > https://metacpan.org/module/MooseX::ClassAttribute
>>>
>>> Very close to what I want, but has this important caveat:
>>>
>>> "All features should just work. The one exception is the "required"
>>> flag, which is not allowed for class attributes."  Since the whole
>>> idea of inheritance was to dictate the child classes incorporated
>>> certain attributes, that doesn't really get me much further.
>>>
>>> Anyway, thanks for the info.
>>>
>>> View Online
>>>
>>> Madison Area Perl Mongers - MadMongers
>>> http://www.madmongers.org
>>
>> Would it be sufficient to check if description() were implemented as an
>> attribute or as a regular method?
>>
>> View Online
>>
>> Madison Area Perl Mongers - MadMongers
>> http://www.madmongers.org
>>
>
> View Online
>
>
>
> Madison Area Perl Mongers - MadMongers
> http://www.madmongers.org
>
> View Online
>
>
>
> Madison Area Perl Mongers - MadMongers
> http://www.madmongers.org