[Dbix-class] RFC: list/array context, TT and search()

[Will Hawes]

Matt S Trout wrote:
> Richard Jolly wrote:
>> Hi,
>>
>> DBIx::Class::AlwaysRS was on my list of things to get around to looking 
>> at. Now it seems to be only available on backpan, though it is still 
>> mentioned in the POD of ResultSetManager and Schema::Loader. Searches of 
>> the catalyst and dbic mailing lists didn't provide much help.
>>
>> As I understood it, it was to aid in the interaction between TT and 
>> DBIx::Class, specifically that TT sometimes provided list context to 
>> resultsets when you really didn't want it.
>>
>> Can someone fill me in more precisely on what the problem was that 
>> AlwaysRS was solving? And why it has been removed from CPAN?
> 
> TT always calls in list context.
> 
> It's been removed because it was class-level and as such didn't work with the 
> resultset model. We've been discussing a better approach - like potentially 
> adding a query/query_related/etc. method that doesn't do the DWIMery based on 
> wantarray, but aren't entirely sure what's best.
> 
> Ideas/comments/suggestions welcome - and that goes for everybody else. 
> Gentlemen, start your mail clients :)
> 

I'd vote for removing wantarray() completely. IMO, if a user wants 
objects rather than a ResultSet, they should call ->all.

Having said that, I realise there are probably others who depend on 
wantarray behaviour by now. How about making the use of wantarray() 
optional? Return a ResultSet by default, but allow the user to set a 
variable to get the current functionality.