Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
2 Dec 2009 at 11:04 UTC
Updated:
20 Dec 2009 at 12:50 UTC
Jump to comment: Most recent file
Comments
Comment #1
Crell commentedI am majorly +1 on this, and in fact believe we should go further than the wrapper functions listed here to all of the methods of those classes, too. Hell, I want it to be Drupal-wide, not just DBTNG.
The catch is that I don't know how it will interact with the API module: #608124: Link function parameter types and return types to class/interface pages
If the API module is OK with it, let's do. It's not an API change IMO.
Comment #2
dries commentedCommitted to CVS HEAD. Let's see what API module does ... and follow-up as necessary. ;-) Leaving at 'needs review'.
Comment #3
berdirThis just added @return SomeClass for the API functions like db_select() and so on. Since we provide a fluent interface ($object->doStuff()->doMoreStuff()) and try to encourage developers to use it, we should also add that to all methods that are fluent. Especially since not all of them all and in some cases, it's not obvious from the method name.
I will probably write patch for this sooner or later (have to get back to business ;)) but I wanted to write it down so that it doesn't get lost/forgotten.
Comment #4
Crell commentedRight then!
If we're going to do it, let's outright do it. There's a lot of code that returns objects now, both DBTNG and otherwise, where we can/should add these tags. I guess we start doing that and let API module decide how it's going to respond. :-) (Last I heard it still didn't deal with classes in the first place, which has to get fixed anyway one way or another.)
I'll update the coding standards page as well.
Comment #5
moshe weitzman commentedHurray! Finally a win for IDE users. Drupal has gone so far down the path of magical array keys [e.g. $options in url(), FAPI properties, ...] that we have quite some clawing back to do.
Comment #6
Crell commentedOK, I went through and tagged other methods and functions as I could find them. I think I got them all. This patch shouldn't do anything outside of docblocks. :-)
It turns out, actually, some of our other non-DB OO code was already defining a return type. Some of it was even buggy. Some of it even defined parameter types! And here I thought I was being a good little coder by not doing that in the DB layer. Ah well.
Comment #7
fagoAwesome!!! Yep API module needs some improvements nevertheless.
@crell:
Patch looks good, but also squashes some empty lines with white-spaces. Not really topic of this issue, but they should be squashed anyway.
Comment #8
Crell commentedMy IDE automatically kills ending whitespace. Yours should to. If you submit a patch that adds trailing whitespace, there's a bug in the patch. :-)
Comment #9
fagoMine does too, but it's nasty if the patch contains hunks unrelated to the real changes. So I turned that off for core.
Comment #10
dries commentedCommitted to CVS HEAD. Thanks Crell.
Comment #11
moshe weitzman commentedMan, this is very very nice. Terrific DX improvement.