develooper Front page | perl.perl5.porters | Postings from December 2010

Re: [perl #80628] [PATCH] __SUB__

Thread Previous | Thread Next
December 14, 2010 09:48
Re: [perl #80628] [PATCH] __SUB__
Message ID:
On 14 December 2010 18:10, Nicholas Clark <> wrote:
> On Mon, Dec 13, 2010 at 07:03:32PM +0100, demerphq wrote:
>> We have also seen that in many environments it is anywhere from nearly
>> impossible to quite difficult to get non-standard modules installed at
>> all, let alone ones that require compiling XS code. We have seen both
>> of these problems with Scalar::Util. (I have personal experience of
>> this one.)
> You're proposing a technical fix to a political problem.

On one level yes, on another level no. Its a technical problem that it
is quite difficult to make recursive closures. The existing technical
solution for doing so is pretty sad. The proiposed solution is vaslty
superior. So why should Perl essentially endorse the shit one and then
say "but the best way you need to install extra modules"

On the other hand yes, we have devs in our community who work in
environments that can be quite restrictive. Your position basically
amounts to saying that you don't care about their opinion or needs. I
dont think that is the way our community should work and I definitely
dont think it is a productive attitude.

> We can't include all of CPAN in the core just because other people wish
> to externalize the costs of resolve their issues.

This is a straw man argument. Nobody is arguing about including all of CPAN.

We are arguing about including critical XS code that cannot reasonably
be simulated in Perl code and which serves a function which
essentially cannot be implemented without XS.

This doesn't apply to pure perl as there is always a workaround in
that a user can always just C&P the code into their own code base if
necessary -- effectively fork the perl code.

This DOES NOT apply to XS code. And even with XS code its not like
anyone is arguing that this applies to a lot code, but rather to a
critical select few pieces that arguably should have been in perl from
the beginning.

> This is one of my hot buttons and I will argue against it until I am driven
> away from Perl 5.

I don't really like the threat here Nicholas, especially given it is
in regard to a position that nobody has taken.

If you really have a good argument for why this idea shouldn't move
forward then post it, but this line about including all of cpan is
just bogus. Bring it up when somebody actually makes that argument ok?


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About