Mailing List Archive

Pre-RFC: Policies
I want to make it easier to reduce boilerplate.

One of my clients had a rule that every Perl module has a standard set of boilerplate at the top of every Perl package/script. I changed that to:

    use Client::Policy;

That made life much easier. I do this a lot for clients and I don't want to keep doing that. However, there were fiddly bits in writing that module. I'd rather write this:

    use feature 'policy';
    policy;

And that reads a .perlpolicy file and automatically injects its contents into the current code.

So if .perlpolicy contains this:

    use v5.26;
    use warnings;
    use feature "signatures';
    no warnings 'experimental::signatures';
    use Carp qw(carp croak);

You don't have to write that every time.

However, we need to consider how the .perlpolicy file is located, and handling the case where you might want different policies for different parts of your code. For example, for Tau Station, we have `Veure::Module`, `Veure::Moose`, and `Veure::Script` depending on our needs. Or if you update Perl, maybe have incremental policies based on the version of Perl?

    policy; # default
    policy 'script';
    policy 'Moose';

This solves a common problem, but I have not yet thought out all of the implications, so I'd love feedback.

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl
Re: Pre-RFC: Policies [ In reply to ]
On Thu, Jan 27, 2022 at 7:24 PM Ovid via perl5-porters <
perl5-porters@perl.org> wrote:

> I want to make it easier to reduce boilerplate.
>
> One of my clients had a rule that every Perl module has a standard set of
> boilerplate at the top of every Perl package/script. I changed that to:
>
> use Client::Policy;
>
> That made life much easier. I do this a lot for clients and I don't want
> to keep doing that. However, there were fiddly bits in writing that module.
> I'd rather write this:
>
> use feature 'policy';
> policy;
>
> And that reads a .perlpolicy file and automatically injects its contents
> into the current code.
>
> So if .perlpolicy contains this:
>
> use v5.26;
> use warnings;
> use feature "signatures';
> no warnings 'experimental::signatures';
> use Carp qw(carp croak);
>
> You don't have to write that every time.
>
> However, we need to consider how the .perlpolicy file is located, and
> handling the case where you might want different policies for different
> parts of your code. For example, for Tau Station, we have `Veure::Module`,
> `Veure::Moose`, and `Veure::Script` depending on our needs. Or if you
> update Perl, maybe have incremental policies based on the version of Perl?
>
> policy; # default
> policy 'script';
> policy 'Moose';
>
> This solves a common problem, but I have not yet thought out all of the
> implications, so I'd love feedback.
>

IMNSHO, that is a terrible idea. That means that the same code will run on
one machine but not the other because they have different .perlpolicy
files. And it won't be obvious at all why it's different. That is extremely
confusing. Policy modules can be useful, but they really need to be named
because otherwise you can't keep everyone in sync and that leads to chaos.

Also, this is the sort of thing that can easily be prototyped on CPAN, and
as such that should be done first.

Leon
Re: Pre-RFC: Policies [ In reply to ]
On Thu, Jan 27, 2022 at 1:24 PM Ovid via perl5-porters <
perl5-porters@perl.org> wrote:

> I want to make it easier to reduce boilerplate.
>
> One of my clients had a rule that every Perl module has a standard set of
> boilerplate at the top of every Perl package/script. I changed that to:
>
> use Client::Policy;
>
> That made life much easier. I do this a lot for clients and I don't want
> to keep doing that. However, there were fiddly bits in writing that module.
> I'd rather write this:
>
> use feature 'policy';
> policy;
>
> And that reads a .perlpolicy file and automatically injects its contents
> into the current code.
>
> So if .perlpolicy contains this:
>
> use v5.26;
> use warnings;
> use feature "signatures';
> no warnings 'experimental::signatures';
> use Carp qw(carp croak);
>
> You don't have to write that every time.
>
> However, we need to consider how the .perlpolicy file is located, and
> handling the case where you might want different policies for different
> parts of your code. For example, for Tau Station, we have `Veure::Module`,
> `Veure::Moose`, and `Veure::Script` depending on our needs. Or if you
> update Perl, maybe have incremental policies based on the version of Perl?
>
> policy; # default
> policy 'script';
> policy 'Moose';
>
> This solves a common problem, but I have not yet thought out all of the
> implications, so I'd love feedback.
>

The CPAN modules https://metacpan.org/pod/Import::Base and
https://metacpan.org/pod/App::MyPerl are existing solutions for this.

-Dan
Re: Pre-RFC: Policies [ In reply to ]
On Thu, Jan 27, 2022 at 06:22:06PM +0000, Ovid via perl5-porters wrote:
> I want to make it easier to reduce boilerplate.
>
> One of my clients had a rule that every Perl module has a standard set of boilerplate at the top of every Perl package/script. I changed that to:
>
> ? ? use Client::Policy;
>
> That made life much easier. I do this a lot for clients and I don't want to keep doing that. However, there were fiddly bits in writing that module. I'd rather write this:
>
> ? ? use feature 'policy';
> ? ? policy;
>
> And that reads a .perlpolicy file and automatically injects its contents into the current code.
>
> So if .perlpolicy contains this:
>
> ? ? use v5.26;
> ? ? use warnings;
> ? ? use feature "signatures';
> ? ? no warnings 'experimental::signatures';
> ? ? use Carp qw(carp croak);
>
> You don't have to write that every time.
>
> However, we need to consider how the .perlpolicy file is located, and handling the case where you might want different policies for different parts of your code. For example, for Tau Station, we have `Veure::Module`, `Veure::Moose`, and `Veure::Script` depending on our needs. Or if you update Perl, maybe have incremental policies based on the version of Perl?
>
> ? ? policy; # default
> ? ? policy 'script';
> ? ? policy 'Moose';
>
> This solves a common problem, but I have not yet thought out all of the implications, so I'd love feedback.

I don't see the advantage over `use Client::Policy;`, `use Client::Policy::Script;'.

Or even `use LocalPolicy 'script';` if the module was more complex.

In both cases the policy is coming from a local file, and with such a
feature (as described) you'd be limited to the mechanisms the feature
provides, while a module is more flexible.

The feature could be made to load the Client::Policy module for extra
flexibility but then you're back where you started.

Tony
Re: Pre-RFC: Policies [ In reply to ]
I don't like this. It would be better to just use a regular named module that
does the same thing. Code like this should always be loaded via the package
system, rather than hidden locale-specific files. The only kind of things that
should be in dotfiles is truly installation-specific stuff and not stuff that is
logically part of the shared codebase, the shared should be in regular modules,
and the boilerplate is shared stuff. -- Darren Duncan

On 2022-01-27 10:22 a.m., Ovid via perl5-porters wrote:
> I want to make it easier to reduce boilerplate.
>
> One of my clients had a rule that every Perl module has a standard set of boilerplate at the top of every Perl package/script. I changed that to:
>
>     use Client::Policy;
>
> That made life much easier. I do this a lot for clients and I don't want to keep doing that. However, there were fiddly bits in writing that module. I'd rather write this:
>
>     use feature 'policy';
>     policy;
>
> And that reads a .perlpolicy file and automatically injects its contents into the current code.
>
> So if .perlpolicy contains this:
>
>     use v5.26;
>     use warnings;
>     use feature "signatures';
>     no warnings 'experimental::signatures';
>     use Carp qw(carp croak);
>
> You don't have to write that every time.
>
> However, we need to consider how the .perlpolicy file is located, and handling the case where you might want different policies for different parts of your code. For example, for Tau Station, we have `Veure::Module`, `Veure::Moose`, and `Veure::Script` depending on our needs. Or if you update Perl, maybe have incremental policies based on the version of Perl?
>
>     policy; # default
>     policy 'script';
>     policy 'Moose';
>
> This solves a common problem, but I have not yet thought out all of the implications, so I'd love feedback.
Re: Pre-RFC: Policies [ In reply to ]
Hi Curtis,

It’s not clear what benefits this offers over creating your own pragma / module, and that’s a well established model for achieving your aims.

For now the PSC has marked this as rejected, in our RFC tracker. If you want to pursue the idea, you’re welcome to try and change our minds, but you’d need to explain what problem this addresses, and it needs to be a problem that is generally experienced, rather than being Veure-specific :-)

Neil
Re: Pre-RFC: Policies [ In reply to ]
That's fine. I realize I won't win 'em all (or even most of them). I had more thoughts on refining the idea, but since it seemd to be an overwhelming "no", I dropped it)

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl






On Thursday, 3 February 2022, 23:07:38 CET, Neil Bowers <neilb@neilb.org> wrote:








Hi Curtis,

It’s not clear what benefits this offers over creating your own pragma / module, and that’s a well established model for achieving your aims.

For now the PSC has marked this as rejected, in our RFC tracker. If you want to pursue the idea, you’re welcome to try and change our minds, but you’d need to explain what problem this addresses, and it needs to be a problem that is generally experienced, rather than being Veure-specific :-)

Neil