[Dbix-class] Resultset accessors for lazy people, and compile-time checking.

Toby Corkindale toby.corkindale at strategicdata.com.au
Thu Apr 16 00:43:03 GMT 2009


Peter Rabbitson wrote:
> Toby Corkindale wrote:
>> Hi,
>> Another task I commonly do in DBIC is to access resultsets from the
>> $schema object, eg:
>>
>> $schema->resultset('MyObject')->find(1);
>>
>> Sometimes I make a mistake, and write:
>> $schema->resultset('MyObjcet')->find(1);
>>
>> However that compiles just fine, and won't get picked up until that bit
>> of code is hit at runtime - when it fails.
>>
>> Now there are two problems here.
>> 1) I like things to fail at compile-time when possible.
>> 2) I am fundamentally lazy and like typing less.
>>
>> Therefore I'd like to propose that DBIC implements direct accessors for
>> resultsets, so that I can type:
>> $schema->MyObject->find(1);
>>
>> and if I type $schema->MyOBject->find(1) then at compile-time I'll get
>> "Can't locate object method "MyOBject" via package My::Schema at foo.pl
>> line nnn" which is helpful.
>>
>>
>> So, how do you feel about this?
> 
> It won't work? :) Perl does not do compile-time method checks, as
> methods can be (and are all over the place) added at runtime.

Ah, oh, yeah. Hmm.
Well, at least one would get the Perl error that does occur at runtime, 
pointing at the correct point in your code, rather than an error inside 
DBIx/Class.pm.
*checks*
Oh, no, that croaks and returns the right line in your code too.

> As far as the laziness argument - seems reasonable, but there is
> something icky about $schema->resultsetname. Can't put my finger on what
> it is exactly that bothers me though. Someone more knowledgeable should
> speak up.

Well, obviously one could get into quite a lot of strife if you had a 
resultset called DESTROY, END, new or resultset, etc - but generally 
your resultsets have sensible names.

You have to admit that typing $schema->resultset('Thing') has to be the 
most common thing you do with DBIC, so abbreviating it to $schema->Thing 
does seem to make good sense for usability, and I think it's about equal 
for readability.

>> I might hack up a patch to do this if I get some spare time, but
>> wondered if greater minds than mine have already considered it and
>> discarded it for being a dreadful idea.
>>
>> (I'm guessing some code wedged into register_class() or thereabouts
>> could do a *{${schema_namespace}::$moniker} = sub { return
>> $self->resultset($monikey) }; or something like that. Alternatively via
>> AUTOLOAD(), but then you lose the compile-time checking.)
> 
> Please please pretty please no AUTOLOAD in dbic code :)

Yeah, that would be bad, even I won't go that far. :)



More information about the DBIx-Class mailing list