Re: [development] Rename *_load and friends
I agree with James on this. There's something elegantly simple about hook_something turns into module_something. How many times something gets fired and for how many modules is something that part of the definition of an api subject to change. I don't see value in tying too much weight to what's called a hook and what's not called a hook. And I don't want to change my intro to teaching module development from "Writing drupal modules is as easy implementing the desired functions in the drupal api that begin with 'hook_'". I also want to see us set the example of having contributed apis start inventing new ways to describe hooks. I'd rather see us all channel the energy into updating the docs for the hooks to be more clear about when those events fire, and for what purpose they are for. Something like: hook_load - use this hook to define the database load event for implementing a new content type in a module. See hook_node_api if you're looking to extend an existing content type. hook_node_api - used to add value to a node implemented by another module. See hook_load ($op='load') if you're looking to define a new content type. We'd modify these docs by submitting core patches, yes? The docs for hook_nodeapi are really good about describing when they should be used. Perhaps we just need to clarify in hook_load* when they should be used. I'm done on this topic.... Dave -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of James Walker Sent: Saturday, January 06, 2007 8:08 AM To: development@drupal.org Subject: Re: [development] Rename *_load and friends On 1/6/07 1:22 AM, Karoly Negyesi wrote:
Hi,
We have had a discussion about this already under a different subject.
My opinion here is that hook_foo is something that gets implemented by N modules and at call time these are called, one after the other. hook_menu , hook_form_alter etc etc Note that 'hook' is always replaced by the module name.
Despite hook_load is called a hook, it's a different animal: at call time, only one implementation is called. Not to mention that since we have a node information hook, 'hook' is not necessarily replaced by the module name.
Larry Garfield suggested calling these method_load, method_view and so
on. This I find a good idea and now would like to get opinions on this
name.
I'm not sure I know why they need different names, and I'm not sure where you draw the line. While I absolutely am +1 for keeping hook_load, etc in addition to hook_nodeapi - I don't know that calling some method_* vs. hook_* really brings all that much clarity. We use "hooks" for *lots* of different things - sometimes pass by reference sometimes by value, with all kinds of different expected return values and behaviours. I don't know how much this single distinction helps. Not to mention, I think we can disappear into a dark hole arguing the semantics (i.e. in OO & AO programming, they're all just called "methods" anyway). The nice thing about the 'hook' name (whether invented or otherwise) is it's easy to teach new developers how hooks relate to the code their looking at, and further that when you see module_foo() you can find full documentation on api.drupal.org by searching for hook_foo. I've done several training sessions now and have not run into a whole lot of confusion from the naming. Fact is, they're not really "methods" - reusing a name with a common, different meaning for most developers may well just add confusion. that's my $0.02 anyway. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
I agree with James on this. There's something elegantly simple about hook_something turns into module_something.
Problem. hook_load does not turn into module_load any more. It's turned into whatever 'module' is defined in hook_node_info Regards NK
On 07 Jan 2007, at 9:11 AM, Karoly Negyesi wrote:
I agree with James on this. There's something elegantly simple about hook_something turns into module_something.
Problem. hook_load does not turn into module_load any more. It's turned into whatever 'module' is defined in hook_node_info
Personally, I favour load_<something> (where something is either the modulename, or modulename_thing). This can be used in a function called drupal_load('something', 'parameter', 'parameter'); (which works in almost exactly the same way we currently do theme functions), But you can also change the functions, by changing the data definitions. This would allow us to hook into the save / load of all our objects. A simple example is finally introducing the top level object/ item type. Every node/user/term/etc could insert a record into the items table. And you could just use load('item', $item_id); to return the item. You could then relate items to each other, instead of having to do the node / user / taxonomy / blah loading / saving / etc. With these functions all being in this way, we can make sure the API is consistent. All load functions must return the object, all update functions must take the object as a reference (for the other modules to hook into). It's always annoyed me how node_save and user_save have different function definitions.
On Mon, 2007-01-08 at 17:42 +0200, adrian rossouw wrote:
On 07 Jan 2007, at 9:11 AM, Karoly Negyesi wrote:
I agree with James on this. There's something elegantly simple about hook_something turns into module_something.
Problem. hook_load does not turn into module_load any more. It's turned into whatever 'module' is defined in hook_node_info
Personally, I favour load_<something> (where something is either the modulename, or modulename_thing).
This can be used in a function called drupal_load('something', 'parameter', 'parameter'); (which works in almost exactly the same way we currently do theme functions), But you can also change the functions, by changing the data definitions.
This would allow us to hook into the save / load of all our objects. A simple example is finally introducing the top level object/ item type.
Every node/user/term/etc could insert a record into the items table. And you could just use load('item', $item_id); to return the item. You could then relate items to each other, instead of having to do the node / user / taxonomy / blah loading / saving / etc.
With these functions all being in this way, we can make sure the API is consistent. All load functions must return the object, all update functions must take the object as a reference (for the other modules to hook into). It's always annoyed me how node_save and user_save have different function definitions.
Then you could get silly and implement them as singleton's and add memcached/someother cache support and get a form of persistent data object in php for drupal.
I want to be on the team which decides which Drupal data collections are inherited objects of this top-level object. Then it's just a tiny bit more work to define all the top-level objects in Drupal, and give them all uniform APIs. ..chrisxj
Oh. My bad on the English grammar, there. I should have written "the team that decides which..."
On 09 Jan 2007, at 1:20 PM, Chris Johnson wrote:
I want to be on the team which decides which Drupal data collections are inherited objects of this top-level object. Then it's just a tiny bit more work to define all the top-level objects in Drupal, and give them all uniform APIs.
Well. just in core i imagine we have node (generic base node) each specific type of node user vocabulary term forum (extends term)
participants (5)
-
adrian rossouw -
Chris Johnson -
Darrel O'Pry -
Karoly Negyesi -
Metzler, David