Bug #114415 for WebService-Solr: BUILDARGS in WebService::Solr::Query prevents subclasses from working properly

Mon May 16 15:25:13 2016 PETDANCE [...] cpan.org - Ticket created

Subject:

BUILDARGS in WebService::Solr::Query prevents subclasses from working properly

Consider this subclass: package My::WebService::Solr::Query; use Moose; extends 'WebService::Solr::Query'; has localparams => ( is => 'ro', isa => 'Str', default => sub { '' } ); 1; This constructor call will pass localparams down into WebService::Solr::Query, where it gets taken as args to the query. my $q = My::WebService::Solr::Query->new( localparams => 'foo' ); I talked to Dave Rolsky who said that the BUILDARGS isn't processing the arguments correctly. For now, I'm working around it by not passing localparams in the constructor to my subclass, and then setting it through a mutator.

Mon May 16 15:49:14 2016 DROLSKY [...] cpan.org - Correspondence added

On Mon May 16 15:25:13 2016, PETDANCE wrote: Show quoted text

> Consider this subclass: > > package My::WebService::Solr::Query; > use Moose; > extends 'WebService::Solr::Query'; > has localparams => ( is => 'ro', isa => 'Str', default => sub { '' } > ); > 1; > > This constructor call will pass localparams down into > WebService::Solr::Query, where it gets taken as args to the query. > > my $q = My::WebService::Solr::Query->new( localparams => 'foo' ); > > I talked to Dave Rolsky who said that the BUILDARGS isn't processing > the arguments correctly. For now, I'm working around it by not > passing localparams in the constructor to my subclass, and then > setting it through a mutator.

The problem is that the BUILDARGS assumes that everything in @_ is a query. However, if a subclass adds attributes, then @_ can contains something like "query => { ... }, subclass_arg => 42", leading to problems. Assuming that a @_ that contains a hash or hashref _doesn't contain_ named attribute params is a bit of anti-pattern.

Mon May 16 15:49:15 2016 The RT System itself - Status changed from 'new' to 'open'