Bug #63543 for Set-Array: More chaining

Thu Dec 02 12:06:48 2010 jpierce [...] cpan.org - Ticket created

Subject:

More chaining

It would be nice if pop and shift could ascertain through context (or a parameter) whether to return the discarded element, or the array so that the method could be chained. Alternatively, cpop, cshift etc. could be offered as chainable variants. Lastly, it would be helpful if the documentation noted which methods were chainable (perhaps starring the method names or something). Otherwise, if one unwittingly tries to chain pop an esoteric method erupts about not being an array ref from line 6XX of the module.

Thu Dec 02 19:42:24 2010 ron [...] savage.net.au - Correspondence added

Subject:	Re: [rt.cpan.org #63543] More chaining
Date:	Fri, 03 Dec 2010 11:41:53 +1100
To:	bug-Set-Array [...] rt.cpan.org
From:	Ron Savage <ron [...] savage.net.au>

Hi Jerrad On Thu, 2010-12-02 at 12:06 -0500, Jerrad Pierce via RT wrote: Show quoted text

> Thu Dec 02 12:06:48 2010: Request 63543 was acted upon. > Transaction: Ticket created by JPIERCE > Queue: Set-Array > Subject: More chaining > Broken in: 0.20 > Severity: Wishlist > Owner: Nobody > Requestors: jpierce@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63543 > > > > It would be nice if pop and shift could ascertain through context (or a > parameter) whether to return the discarded element, or the array so that > the method could be chained. Alternatively, cpop, cshift etc. could be > offered as chainable variants.

pop() and shift() already return either the element or the element blessed, so I think it's too complex to try making them also return the underlying object in some cases. Hence, I've implemented cpop() and cshift(), as suggested. Show quoted text

> Lastly, it would be helpful if the documentation noted which methods > were chainable (perhaps starring the method names or something). > Otherwise, if one unwittingly tries to chain pop an esoteric method > erupts about not being an array ref from line 6XX of the module.

I think you mean line 426 (or thereabouts) :-). I would have to annotate more-or-less every method :-(. I checked. The other problem of course is that the chain-ability depends on the context, it's not a can-or-can't binary fact. I suggest you'll just have to get used to reading the section on OBJECT BEHAVIOR. I'm releasing V 0.21 now. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622

Thu Dec 02 19:42:25 2010 The RT System itself - Status changed from 'new' to 'open'

Thu Dec 02 21:25:29 2010 RSAVAGE [...] cpan.org - Correspondence added

Hi I've patched V 0.21 to take you suggestions into account. HTH.

Thu Dec 02 21:25:30 2010 RSAVAGE [...] cpan.org - Status changed from 'open' to 'resolved'

Wed Dec 08 00:16:42 2010 belg4mit [...] pthbb.org - Correspondence added

Subject:	Re: [rt.cpan.org #63543] AutoReply: More chaining
Date:	Wed, 08 Dec 2010 00:16:33 -0500
To:	bug-Set-Array [...] rt.cpan.org
From:	belg4mit [...] pthbb.org

unique() could also be usefully chained, some might also consider that a form of compaction, so it might be accessible by passing a aparameter to compact, though cunique would be adequate. Or maybe unique should not return the output of duplicates()? Just a thought

Wed Dec 08 00:16:42 2010 The RT System itself - Status changed from 'resolved' to 'open'

Wed Dec 08 01:38:39 2010 ron [...] savage.net.au - Correspondence added

Subject:	Re: [rt.cpan.org #63543] AutoReply: More chaining
Date:	Wed, 08 Dec 2010 17:38:19 +1100
To:	bug-Set-Array [...] rt.cpan.org
From:	Ron Savage <ron [...] savage.net.au>

Hi On Wed, 2010-12-08 at 00:16 -0500, belg4mit@pthbb.org via RT wrote: Show quoted text

> Queue: Set-Array > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=63543 > > > unique() could also be usefully chained, some might also consider that a form of > compaction, so it might be accessible by passing a aparameter to compact, though > cunique would be adequate.

The Synopsis has an example of unique being chained. Show quoted text

> Or maybe unique should not return the output of duplicates()?

I don't understand this statement. unique() and duplicates() are basically opposites. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622

Wed Dec 08 23:48:27 2010 belg4mit [...] pthbb.org - Correspondence added

Subject:	Re: [rt.cpan.org #63543] AutoReply: More chaining
Date:	Wed, 08 Dec 2010 23:48:18 -0500
To:	bug-Set-Array [...] rt.cpan.org
From:	belg4mit [...] pthbb.org

Show quoted text

>> unique() could also be usefully chained, some might also consider that a form of >> compaction, so it might be accessible by passing a aparameter to compact, though >> cunique would be adequate.

> >The Synopsis has an example of unique being chained. >

>> Or maybe unique should not return the output of duplicates()?

> >I don't understand this statement. unique() and duplicates() are >basically opposites.

TFM for unique() says Removes/returns non-unique elements from the list. This to me read/reads as if: my $sao = Set::Array->new(1,2,3,2,3); my @uniq = $sao->unique(); Would not do what the comments state, and actual behavior is: # Object unmodified. '@uniq' contains 3 values. But instead: @uniq = (2, 3); $sao = a Set::Array of 1,2,3 In other words it removes the non-unique elements and returns them (aka the outout of duplicates), with the implicit modification of the object. So the original notion of cunique is indeed pointless. But the description of it is misleading. it should instead be something like: Removes duplicates() (non-unique) elements from the list, and returns a Set::Array object of the remaining elements.

Thu Dec 09 00:31:48 2010 ron [...] savage.net.au - Correspondence added

Subject:	Re: [rt.cpan.org #63543] AutoReply: More chaining
Date:	Thu, 09 Dec 2010 16:31:25 +1100
To:	bug-Set-Array [...] rt.cpan.org
From:	Ron Savage <ron [...] savage.net.au>

Hi Comments below. On Wed, 2010-12-08 at 23:48 -0500, belg4mit@pthbb.org via RT wrote: Show quoted text

> Queue: Set-Array > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=63543 > >

> >> unique() could also be usefully chained, some might also consider that a form of > >> compaction, so it might be accessible by passing a aparameter to compact, though > >> cunique would be adequate.

> > > >The Synopsis has an example of unique being chained. > >

> >> Or maybe unique should not return the output of duplicates()?

> > > >I don't understand this statement. unique() and duplicates() are > >basically opposites.

> > TFM for unique() says > > Removes/returns non-unique elements from the list. > > This to me read/reads as if: > > my $sao = Set::Array->new(1,2,3,2,3); > my @uniq = $sao->unique(); > > Would not do what the comments state, and actual behavior is: > > # Object unmodified. '@uniq' contains 3 values. > > But instead: > > @uniq = (2, 3); > $sao = a Set::Array of 1,2,3 > > In other words it removes the non-unique elements and returns them > (aka the outout of duplicates), with the implicit modification of the object. > > So the original notion of cunique is indeed pointless. But the description of > it is misleading. it should instead be something like: > > Removes duplicates() (non-unique) elements from the list, > and returns a Set::Array object of the remaining elements.

You are correct. I'll patch the POD. Don't forget I did not write this module. I took maintenance of it when I found bugs in the handling of 0, and the original author didn't want to keep working with it. So, I just patch things as they arise. I haven't proof-read the spec of every method :-). -- Ron Savage http://savage.net.au/ Ph: 0421 920 622

Thu Dec 09 04:18:40 2010 RSAVAGE [...] cpan.org - Correspondence added

Hi I've released V 0.22 with patches to the docs for: compact(), delete(), duplicates(), reverse(), sort() and unique() and specific tests for unique() in scalar, list and chained contexts.

Thu Dec 09 04:18:41 2010 RSAVAGE [...] cpan.org - Status changed from 'open' to 'resolved'