Skip Menu |
 

This queue is for tickets about the List-MoreUtils CPAN distribution.

Report information
The Basics
Id: 17230
Status: resolved
Priority: 0/
Queue: List-MoreUtils

People
Owner: Nobody in particular
Requestors: mark [...] summersault.com
Cc:
AdminCc:

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



Subject: wish: arrayify
Download (untitled) / with headers
text/plain 1.1k
Here's a pattern I see frequently in my own code that I think deserves a utility function: I have a scalar that either holds a single value or an array reference that holds multiple values. I want to always be table to treat the thing as an an array in either use. Use cases: CGI.pm's param() method returns either a single value or multiple values. Once translated into a hash, you have this kind of data structure. Throughout the Data::FormValidator interface, you can give simple scalar values for simple cases, or an arrayref of values for more complex cases. A function for this is implemented internally in Data::FormValidator, and has worked well over the years. Here it is: # takes string or array ref as input # returns array sub arrayify { # if the input is undefined, return an empty list my $val = shift; defined $val or return (); if ( ref $val eq 'ARRAY' ) { # if it's a reference, return an array unless it points an empty array. -mls return (defined $val->[0]) ? @$val : (); } else { # if it's a string, return an array unless the string is missing or empty. -mls return (length $val) ? ($val) : (); } }
Subject: Re: [rt.cpan.org #17230] wish: arrayify
Date: Mon, 23 Jan 2006 18:34:11 +0100
To: Guest via RT <bug-List-MoreUtils [...] rt.cpan.org>
From: Tassilo von Parseval <tassilo.von.parseval [...] rwth-aachen.de>
Download (untitled) / with headers
text/plain 2.4k
Hi there, On Mon, Jan 23, 2006 at 11:27:11AM -0500 Guest via RT wrote: Show quoted text
> Mon Jan 23 11:27:11 2006: Request 17230 was acted upon. > Transaction: Ticket created by guest > Queue: List-MoreUtils > Subject: wish: arrayify > Owner: Nobody > Requestors: mark@summersault.com > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=17230 > > > > Here's a pattern I see frequently in my own code that I think deserves a > utility function: > > I have a scalar that either holds a single value or an array reference > that holds multiple values. I want to always be table to treat the > thing as an an array in either use. > > Use cases: > > CGI.pm's param() method returns either a single value or multiple > values. Once translated into a hash, you have this kind of data structure. > > Throughout the Data::FormValidator interface, you can give simple scalar > values for simple cases, or an arrayref of values for more complex cases. > > A function for this is implemented internally in Data::FormValidator, > and has worked well over the years. Here it is: > > # takes string or array ref as input > # returns array > sub arrayify { > # if the input is undefined, return an empty list > my $val = shift; > defined $val or return (); > > if ( ref $val eq 'ARRAY' ) { > # if it's a reference, return an array unless it points an empty > array. -mls > return (defined $val->[0]) ? @$val : (); > } > else { > # if it's a string, return an array unless the string is missing > or empty. -mls > return (length $val) ? ($val) : (); > } > }
Sure, I'll put that into List::MoreUtils. One small thing however: I'll rather call it 'listify' as functions cannot really return arrays. There's one further question arising from that. Should this function do something special in scalar context? As it is written above, it will return the length of the list if $val was an array-ref, otherwise $val (or undef). Also, I am not sure about the ref-branch as it is right now. For something like arrayify( [undef, 0, 1, 2] ); it'll return the empty list as the first element is undef. So I think it should simply do: return @$val if ref $val eq 'ARRAY'; That will also cover the case that $val == [] by returning an empty list. Could you clarify the above issues? Cheers, Tassilo -- use bigint; $n=71423350343770280161397026330337371139054411854220053437565440; $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
Subject: Re: [rt.cpan.org #17230] wish: arrayify
Date: Mon, 23 Jan 2006 12:53:30 -0500
To: Tassilo von Parseval via RT <bug-List-MoreUtils [...] rt.cpan.org>
From: Mark Stosberg <mark [...] summersault.com>
Download (untitled) / with headers
text/plain 1.3k
On Mon, Jan 23, 2006 at 12:35:08PM -0500, Tassilo von Parseval via RT wrote: Show quoted text
> > Sure, I'll put that into List::MoreUtils. One small thing however: I'll > rather call it 'listify' as functions cannot really return arrays.
That's fine with me. Show quoted text
> There's one further question arising from that. Should this function do > something special in scalar context? As it is written above, it will > return the length of the list if $val was an array-ref, otherwise $val > (or undef).
I like the idea that would return the same thing in a scalar context than array would, which I believe is the length of the list. Show quoted text
> Also, I am not sure about the ref-branch as it is right now. For > something like > > arrayify( [undef, 0, 1, 2] ); > > it'll return the empty list as the first element is undef. So I think it > should simply do: > > return @$val if ref $val eq 'ARRAY'; > > That will also cover the case that $val == [] by returning an empty > list. > > Could you clarify the above issues?
I agree that's probably an improvement for the general case. The version I had in Data::FormValidator has worked fine there, but this version will be used in more contexts. Your revised logic does look like the the 'obvious' implementation, that is more likely to do what people expect. A nice refactoring. :) Thanks for the prompt response. Mark
Subject: Re: [rt.cpan.org #17230] wish: arrayify
Date: Mon, 23 Jan 2006 20:00:59 +0100
To: "mark [...] summersault.com via RT" <bug-List-MoreUtils [...] rt.cpan.org>
From: Tassilo von Parseval <tassilo.von.parseval [...] rwth-aachen.de>
Download (untitled) / with headers
text/plain 1.1k
On Mon, Jan 23, 2006 at 12:54:17PM -0500 mark@summersault.com via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=17230 > > > On Mon, Jan 23, 2006 at 12:35:08PM -0500, Tassilo von Parseval via RT wrote:
Show quoted text
> > Could you clarify the above issues?
> > I agree that's probably an improvement for the general case. The version > I had in Data::FormValidator has worked fine there, but this version > will be used in more contexts. Your revised logic does look like the > the 'obvious' implementation, that is more likely to do what people > expect. > > A nice refactoring. :)
That was only an attempt at making the sub as terse and concise as possible. The final version will be even more rigorously refactored. ;-) Show quoted text
> Thanks for the prompt response.
No problem. Note that I have put your mail on the agenda for the next release of which I am not certain when it will happen. I am right now rather overloaded with many things. But it will happen. Cheers, Tassilo -- use bigint; $n=71423350343770280161397026330337371139054411854220053437565440; $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.