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. _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/