Skip Menu |

This queue is for tickets about the sub-curry CPAN distribution.

Report information
The Basics
Id: 47664
Status: rejected
Priority: 0/
Queue: sub-curry

People
Owner: lodin [...] cpan.org
Requestors: mschwern [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.8
Fixed in: (no value)



Subject: [PATCH] Export curry() and HOLE by default
Hi, I came across Sub::Curry, went to use it and then saw that curry() wasn't exported by default! As that's the major point of the module it seems silly not to. I threw in HOLE as that seems like its going to be used a lot. Its easier and shorter to stop exporting (use Sub::Curry ();) than it is to make it happen (use Sub::Curry qw(curry HOLE)). See also http://use.perl.org/comments.pl?sid=36423&cid=56862 for a defense of the reasonable use of @EXPORT. While I was in there I made a small improvement to the basic tests.
Subject: 0002-Export-the-most-common-routines-curry-and-HOLE.patch
From bc125ccafc7e04efae2a14198ae09510cf40685f Mon Sep 17 00:00:00 2001 From: Michael G. Schwern <schwern@pobox.com> Date: Tue, 7 Jul 2009 13:52:49 -0700 Subject: [PATCH 2/2] Export the most common routines, curry() and HOLE. Its easier to make the minority write "use Sub::Curry ()" then to make the majority write "use Sub::Curry qw(curry HOLE)" --- MANIFEST | 9 +++++---- lib/Sub/Curry.pm | 12 +++++------- t/default_export.t | 6 ++++++ 3 files changed, 16 insertions(+), 11 deletions(-) create mode 100644 t/default_export.t diff --git a/MANIFEST b/MANIFEST index b0056d7..285de19 100644 --- a/MANIFEST +++ b/MANIFEST @@ -1,10 +1,11 @@ Changes +lib/Sub/Curry.pm +lib/Sub/Curry/Cookbook.pod LICENSE -MANIFEST Makefile.PL +MANIFEST +META.yml Module meta-data (added by MakeMaker) README -lib/Sub/Curry.pm -lib/Sub/Curry/Cookbook.pod t/01basic.t t/02spices.t -META.yml Module meta-data (added by MakeMaker) +t/default_export.t diff --git a/lib/Sub/Curry.pm b/lib/Sub/Curry.pm index 86d4245..7b4e897 100644 --- a/lib/Sub/Curry.pm +++ b/lib/Sub/Curry.pm @@ -30,9 +30,9 @@ BEGIN { our %EXPORT_TAGS = ( CONST => [ @consts ], ); - our @EXPORT_OK = qw/ curry /; - push @EXPORT_OK => map @$_ => values %EXPORT_TAGS; - $EXPORT_TAGS{ALL} = \@EXPORT_OK; + our @EXPORT = qw/ curry HOLE /; + our @EXPORT_OK = map @$_ => values %EXPORT_TAGS; + $EXPORT_TAGS{ALL} = [@EXPORT_OK, @EXPORT]; } sub spice_eq { @@ -258,8 +258,6 @@ Sub::Curry - Create curried subroutines =head1 SYNOPSIS use Sub::Curry; - use Sub::Curry qw/ :CONST curry /; # Import spice constants - # and the &curry function. #my $f1 = Sub::Curry::->new(\&foo, 1, 2); # Same as below. my $f1 = curry(\&foo, 1, 2); @@ -395,7 +393,7 @@ Returns a copy of the subroutine/object that isn't blessed, i.e. lost all its pr =head1 EXPORTED SYMBOLS -No symbols are exported by default. C<:ALL> exports all functions. C<:CONST> exports all constants. +The commonly used C<curry> and C<HOLE> are exported by default. C<:ALL> exports all functions. C<:CONST> exports all constants. =head2 Functions @@ -480,4 +478,4 @@ L<Callback> L<Sub::DeferredPartial> -=cut \ No newline at end of file +=cut diff --git a/t/default_export.t b/t/default_export.t new file mode 100644 index 0000000..2c662ba --- /dev/null +++ b/t/default_export.t @@ -0,0 +1,6 @@ +#!/usr/bin/perl -w + +use Sub::Curry; +use Test::More tests => 1; + +can_ok __PACKAGE__, qw(curry HOLE); -- 1.6.2.4
Subject: 0001-Use-is-instead-of-ok-and-eq-for-better-diagnostics.patch
From 4f6714bcab2cbdba93818e23a4775ccc3595cbfc Mon Sep 17 00:00:00 2001 From: Michael G. Schwern <schwern@pobox.com> Date: Tue, 7 Jul 2009 13:48:33 -0700 Subject: [PATCH 1/2] Use is() instead of ok and eq for better diagnostics. --- t/01basic.t | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/t/01basic.t b/t/01basic.t index b7ca670..208b9bb 100644 --- a/t/01basic.t +++ b/t/01basic.t @@ -10,16 +10,16 @@ use Scalar::Util qw/ reftype blessed /; BEGIN { eval { package Foo1; Sub::Curry::->import(qw/ curry /) }; - ok($@ eq '', 'import'); + is($@, '', 'import'); eval { package Foo2; Sub::Curry::->import(qw/ :CONST /) }; - ok($@ eq '', 'import'); + is($@, '', 'import'); eval { package Foo3; Sub::Curry::->import(qw/ BLACKHOLE /) }; - ok($@ eq '', 'import'); + is($@, '', 'import'); eval { package Foo; Sub::Curry::->import(qw/ :ALL /) }; - ok($@ eq '', 'import'); + is($@, '', 'import'); } use Sub::Curry ':ALL'; -- 1.6.2.4
Subject: Re: [rt.cpan.org #47664] [PATCH] Export curry() and HOLE by default
Date: Mon, 24 Aug 2009 21:55:58 +0200
To: bug-sub-curry [...] rt.cpan.org
From: "Johan Lodin" <lodin [...] cpan.org>
Hello Michael,

Thank you for your effort and patches. Unfortunately, I'm not sure I agree with that the major point of Sub::Curry is to use &curry (and HOLE). This was the point of Sub::Curry version 0.08, but the focus has changed since then. As I say in the documentation "This module aims to be a base for other modules that use/provide currying techniques." That is why I have an OO interface that lets you access and modify the curried subroutine. The OO interface is really the main interface and &curry should be considered an optional part for those that are not interested in the rest of the interface.

I know one can do "use Sub::Curry ();" to stop it from exporting the defaults, but in general I prefer to let modules do what the user asks for and not force the user to stop the module from doing things. This is particularly relevant for this module as the main interface is the OO interface.

As I mentioned above; Sub::Curry is not targeted for simple currying and is really only needed if you don't know the structure of the spice when writing the currying code. As an end user that curries a particular subroutine you can usually do without Sub::Curry quite trivially. Here are some examples.

    # Hole:
    sub { foo($_[0], 'extra', @_[1 .. $#_]) }
    sub { splice, @_, 1, 0, 'extra'; goto &foo }

    # Blackhole:
    sub { foo(@_, 'extra') }
    sub { push @_, 'extra'; goto &foo }

    # Antispice 1
    sub { shift; goto &foo }

    # Antispice 2
    sub { foo(@_[1, 3, 6]) }
    sub { splice @_, $_, 1 for reverse 0, 2, 4, 5; goto &foo }

So if you know how you want to curry a subroutine, and in particular if you don't care about caller(), then you can use a simple wrapper. (Whiteholes and antiholes are only applicable for spice modification.)

In summary; I consider &curry to be the odd part of the interface, and if you only use &curry and e.g. HOLE to do plain currying then you probably don't need to use this module anyway. Personally I don't use Sub::Curry for simple currying, but if you want to then please do. :-)

Regards,
Johan Lodin


On Tue, 07 Jul 2009 16:59:46 -0400
"Michael G Schwern via RT" wrote:
> Tue Jul 07 16:59:45 2009: Request 47664 was acted upon.
> Transaction: Ticket created by MSCHWERN
> Queue: sub-curry
> Subject: [PATCH] Export curry() and HOLE by default
> Broken in: 0.8
> Severity: Wishlist
> Owner: Nobody
> Requestors: mschwern@cpan.org
> Status: new
> Ticket
>https://rt.cpan.org/Ticket/Display.html?id=47664 >
>
>
> Hi, I came across Sub::Curry, went to use it and then
>saw that curry()
> wasn't exported by default! As that's the major point
>of the module it
> seems silly not to. I threw in HOLE as that seems like
>its going to be
> used a lot.
>
> Its easier and shorter to stop exporting (use Sub::Curry
>();) than it is
> to make it happen (use Sub::Curry qw(curry HOLE)).
>
> See also
>http://use.perl.org/comments.pl?sid=36423&amp;cid=56862 for a
> defense of the reasonable use of @EXPORT.
>
> While I was in there I made a small improvement to the
>basic tests.
>

Subject: Re: [rt.cpan.org #47664] [PATCH] Export curry() and HOLE by default
Date: Sun, 30 Aug 2009 12:40:45 -0700
To: bug-sub-curry [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Johan Lodin via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=47664 > > > Thank you for your effort and patches. Unfortunately, I'm not sure I agree with > that the major point of Sub::Curry is to use &curry (and HOLE). This was the > point of Sub::Curry version 0.08, but the focus has changed since then. As I > say in the documentation "This module aims to be a base for other modules that > use/provide currying techniques." That is why I have an OO interface that lets > you access and modify the curried subroutine. The OO interface is really the > main interface and &curry should be considered an optional part for those that > are not interested in the rest of the interface.
From the perspective reading the docs this intent is not clear. The synopsis and cookbook relies mainly on curry(). There's no docs about how one goes about using Sub::Curry as a base for your module. I think the docs need a rewrite to make this all clear. Show quoted text
> As I mentioned above; Sub::Curry is not targeted for simple currying and is > really only needed if you don't know the structure of the spice when writing > the currying code. As an end user that curries a particular subroutine you can > usually do without Sub::Curry quite trivially. Here are some examples.
Yes, if I wanted to do it by hand I wouldn't be using a module. :) -- But there's no sense crying over every mistake. You just keep on trying till you run out of cake. -- Jonathan Coulton, "Still Alive"