Extending the factory

[ThisUsedToBeAnEmail]

Hi I'm wondering whether something like the following is possible.

package Mxpress::PDF::Plugin::Mechanized;
use Zydeco factory_package => 'Mxpress::PDF';
class Plugin::Mechanized {
    extends Plugin::Image;
    factory mechanized (Object $file, Map %args) {
        $class->new(
            file => $file
            %args
        );
    }
    # ....
}
1;

my-script.pl

use Mxpress::PDF;
use Mxpress::PDF::Plugin::Mechanized;

[tobyink]

Wow, I only just looked at this now, but coincidentally it's along the lines of what I've been doing today.

The following test is currently passing:

use strict;
use warnings;
use Test::More;
use Test::Fatal;

package MyApp {
        use Zydeco;
        class Foo;
}

package MyApp {
        use Zydeco;
        class Bar {
                has foo (type => Foo);
        }
}

my $foo = MyApp->new_foo;
my $bar = MyApp->new_bar(foo => $foo);

isnt(
        exception { $bar->foo(undef) },
        undef,
);

done_testing;

So yeah, you should be able to load more classes as plugins.

[tobyink]

Also, I really want to have a hook that roles can do, like:

role Plugin {
  on_compose {
    ...;
  }
}

So the on_compose code gets called every time a class (or other role) consumes the Plugin role. It's not easy to do but should be possible.

So if all your plugins included with Plugin, then the main PDF class would be able to grab a list of plugins easily.

[ThisUsedToBeAnEmail]

Really, Sounds like a nice feature.

Crazy idea: What I'd like is it to compile into a .pmc so that it is faster after the first run. Having that will likely also help aid with OAPs using Zydeco because they will know, for production they have sane pure perl code (or even crazy fast xs.)

On Tue, 18 Feb 2020, 07:12 Toby Inkster, notifications@github.com wrote:

Also, I really want to have a hook that roles can do, like:

role Plugin { on_compose { ...; } }

So the on_compose code gets called every time a class (or other role) consumes the Plugin role. It's not easy to do but should be possible.

So if all your plugins included with Plugin, then the main PDF class would be able to grab a list of plugins easily.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tobyink/p5-zydeco/issues/1?email_source=notifications&email_token=AD3HJ33WTAWPJ4FO7GYWXJ3RDMRYPA5CNFSM4KWA27TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMACAYA#issuecomment-587210848, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HJ33YJV4SP2YTYKDVIZ3RDMRYPANCNFSM4KWA27TA .

[ThisUsedToBeAnEmail]

Its just my opinion but new and shiny scare people. So making it transparent might make it that little more awesome.

On Tue, 18 Feb 2020, 07:28 LNATION ., thisusedtobeanemail@gmail.com wrote:

Really, Sounds like a nice feature.

Crazy idea: What I'd like is it to compile into a .pmc so that it is faster after the first run. Having that will likely also help aid with OAPs using Zydeco because they will know, for production they have sane pure perl code (or even crazy fast xs.)

On Tue, 18 Feb 2020, 07:12 Toby Inkster, notifications@github.com wrote:

Also, I really want to have a hook that roles can do, like:

role Plugin { on_compose { ...; } }

So the on_compose code gets called every time a class (or other role) consumes the Plugin role. It's not easy to do but should be possible.

So if all your plugins included with Plugin, then the main PDF class would be able to grab a list of plugins easily.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tobyink/p5-zydeco/issues/1?email_source=notifications&email_token=AD3HJ33WTAWPJ4FO7GYWXJ3RDMRYPA5CNFSM4KWA27TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMACAYA#issuecomment-587210848, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HJ33YJV4SP2YTYKDVIZ3RDMRYPANCNFSM4KWA27TA .

[tobyink]

You can kind of get that already with use Zydeco debug => 1. It will dump a big Data::Dumper hashref structure suitable for passing to MooX::Press.

You want:

BEGIN { $Data::Dumper::Deparse = 1 };

Dealing with closed-over lexical variables is left as an exercise for the reader.

[ThisUsedToBeAnEmail]

I just had this thought and now I understand the point.