But I'm not sure if attributes are lexicaly scoped? I don't want to define "bold" or "div_id" attribute in any module. I want it only in this one module.
def bold(func):
def wrapper(str):
return '<b>' + func(str) + '</b>'
return wrapper
def div_id(id):
def decorator(func):
def wrapper(str):
return (('<div id="%s">' % id) + func(str) + '</div>')
return wrapper
return decorator
@div_id("testid")
@bold
def p(str):
return '<p>' + str + '</p>'
print p("test")
And you know what? There is Python::Decorator module which mimics this exact syntax:
use v5.14;
use Python::Decorator;
sub bold {
my ($orig) = @_;
return sub {
return '<b>' . $orig->(@_) . '</b>';
};
}
sub div_id {
my ($id) = @_;
return sub {
my ($orig) = @_;
return sub {
return "<div id=\"$id\">" . $orig->(@_) . '</div>';
};
};
}
@div_id("testid")
@bold
sub p {
my ($str) = @_;
return "<p>$str</p>";
};
say p('test');
This is a proof of concept rather than code for production. I wouldn't use source filter which calls PPI parser, but the idea is very nice. Only if the Perl could do this in more perlish way...
But wait, we have wonderful Moose with its method modifiers and it is really clear now that Python's decorator is simple "around" modifier.
There is my proof of concept which defined new keyword "decorate".
use v5.14;
use Moose;
sub bold {
my ($orig, $self, @args) = @_;
return '<b>' . $self->$orig(@args) . '</b>';
};
sub div_id {
my ($id) = @_;
return sub {
my ($orig, $self, @args) = @_;
return "<div id=\"$id\">" . $self->$orig(@args) . '</div>';
}
}
# new keyword
sub decorate ($@) {
my ($name, @decorators) = @_;
while (my $decorator = pop @decorators) {
my $body = ref $decorator eq 'CODE' ? $decorator : __PACKAGE__->meta->get_method($decorator)->body;
Moose::Util::add_method_modifier(__PACKAGE__, 'around', [ [ $name ], $body ]);
}
}
sub p {
my ($str) = @_;
return "<p>$str</p>";
};
decorate p => div_id('testid'), 'bold';
say p('test');
I wonder if it is worth of own MooseX module. Nevertheless, this pattern can be useful if you want to port some Python code.
I wrote some note about frustration because of tool itself and some repos without Makefile.PL
All I please (politely) is to use some Git::CommitBuild plugin or other solution and redistribute plain old Makefile.PL or Build.PL. At least in one of branches. Of course, your repos = your rules. And less chance that someone wants to contribute to your repo.
I don't want any build infrastructure. All I want is to *install* the package from the latest source from git repository. Waiting for release on cpan.org is so oldschool.
Look at the other tools: Composer from PHP and PIP from Python. They can also install modules by cloning the git repository. This is just an ordinary user want. If you dissallow to use your repository via cpanminus it is like middle finger to your users. Very unfriendly, IMO.
prove -l -I../Other-Repo/lib -I../Something-More-Repo/lib -I../And/Another/Broken/Because/Of/Dist/Zilla/Repo
but it is pure nonsense and gives me a lot of unnecessary work because all I want is
$ cpanm git://github.com/some/RepoCloning git://github.com/some/Repo ... OK
--> Working on git://github.com/some/Repo
Configuring /sdcard/home/tmp/uOEfC3nBE4 ... N/A
! The distribution doesn't have a proper Makefile.PL/Build.PL See /sdcard/home/.cpanm/work/1389798046.23933/build.log for details.
Oh, crap...
]]>Waiting for original author and is release before I can go with *MY* tests is real pain in the ass.
I see so many people just resign from sending the patches because of Dist::Zilla, so I already sure that it is the problem with this tool, not just my imagination.
It is more annoying to run dzil build and see
Required plugin bundle [@YETANOTHER] isn't installed.
I don’t want to install 300 more packages only because I need this only one small module which I cloned from git repository. I can’t install 300 more packages for Dzil because I do it on Android where there is no Dzill because I need to fix some modules which I can’t fix because of missing Dzil. Damn it.
Dist::Zilla: real Catch-22
Fortunately usually I can prepare tiny stub with Makefile.PL:
# Very simple stub because of damn Dist::Zilla
use ExtUtils::MakeMaker;
WriteMakefile( 'PL_FILES' => {}, 'VERSION' => '0.01', 'EXE_FILES' => [] );
Stupid? If it’s stupid and it works, it’s not stupid. ExtUtils::MakeMaker beats Dist::Zilla.
]]>Thread 88 terminated abnormally: failed to set socket to nonblocking mode:An operation was attempted on something that is not a socket. at C:/strawberry/perl/site/lib/Thrall/Server.pm line 113.
and a few requests are failed. Perl on Windows still sucks...
]]>So I wrote Thrall: multithreaded Plack server for Windows. To be strict - it is hacked Starlet server with preforking removed, so now works with Perl on Windows correctly.
Well, I've noticed that threads are really stable and useful and its API is very nice. It is only one thing that breaks everything: threads::shared. It is horribly unstable and broken on Windows, so I avoided it as far as simple server might not to need it. Spawning new threads is very slow, so it is suggested to use large value for --max-reqs-per-child option.
It is interesting, that Thrall can be converted automagically to preforking server when it is started with -Mforks option/
]]>