The array argument in hook_user: can we get rid of it?
Unlike our other object hooks (e.g., hook_nodeapi, hook_taxonomy), hook_user passes two arguments by reference. Both are representations of the user object, one in array and the other in object format. There's a lot of interest in streamlining our object handling. I've been working on a set of generalized object handling methods that build on our current ones in http://drupal.org/node/113435. As I dig into this, I'm finding that hook_user's difference from our other hooks is one of the main barriers. Maintaining this double pass by reference would force all other object types to do the same, even though they don't have data they need to pass. Hence my question: can we change hook_user to behave like the other object hooks, passing a single argument (the user object) by reference? Pitfalls? Looking at the implementations in user.module, this double passing looks to be mainly a matter of convenience--separating out what are parameters to match (user_load()) or extended user attributes (user_save()) from the base user object. My hunch is, if they're user data they're user data as far as hook implementations are concerned, so it shouldn't matter much if they're passed in a single object. But maybe this is wishful thinking. I'm thinking a patch to change hook_user to pass a single argument by preference may be a necessary prior patch to getting a generalized set of methods in. Thoughts?
Nedjo Rogers wrote:
Unlike our other object hooks (e.g., hook_nodeapi, hook_taxonomy), hook_user passes two arguments by reference. Both are representations of the user object, one in array and the other in object format.
There's a lot of interest in streamlining our object handling. I've been working on a set of generalized object handling methods that build on our current ones in http://drupal.org/node/113435.
As I dig into this, I'm finding that hook_user's difference from our other hooks is one of the main barriers. Maintaining this double pass by reference would force all other object types to do the same, even though they don't have data they need to pass.
Hence my question: can we change hook_user to behave like the other object hooks, passing a single argument (the user object) by reference? Pitfalls?
Looking at the implementations in user.module, this double passing looks to be mainly a matter of convenience--separating out what are parameters to match (user_load()) or extended user attributes (user_save()) from the base user object. My hunch is, if they're user data they're user data as far as hook implementations are concerned, so it shouldn't matter much if they're passed in a single object. But maybe this is wishful thinking.
I'm thinking a patch to change hook_user to pass a single argument by preference may be a necessary prior patch to getting a generalized set of methods in. Thoughts?
THe reason hook_user works like that is so that you can edit only part of a user object, which is currently a necessity for profile module. Changing the structure may well be a good idea, but will have very widespread ramifications, and will need a way to retain the current abilities.
On Tue, 06 Feb 2007 11:39:52 -0800, Earl Miles <merlin@logrus.com> wrote:
Nedjo Rogers wrote:
Unlike our other object hooks (e.g., hook_nodeapi, hook_taxonomy), hook_user passes two arguments by reference. Both are representations of the user object, one in array and the other in object format.
THe reason hook_user works like that is so that you can edit only part of a user object, which is currently a necessity for profile module.
Having to pass the array is really annoying, especially since you need to call user_save separately with "category" values as well as the array of data you want to save! All you should really need to do is call a user_save($user) with a fully updated user object (or array ;)). Profile module knows which fields it is responsible for, I can't see why it needs to rely on a separate edit array and category value to tell it what it already knows based on the {profile_fields} table. The main trick is that each module that adds data to the user object needs to remember to unset() the values it is responsible for, lest they be serialized into the {user}.data graveyard. -Rowan
Rowan Kerr wrote:
On Tue, 06 Feb 2007 11:39:52 -0800, Earl Miles <merlin@logrus.com> wrote:
Nedjo Rogers wrote:
Unlike our other object hooks (e.g., hook_nodeapi, hook_taxonomy), hook_user passes two arguments by reference. Both are representations of the user object, one in array and the other in object format. THe reason hook_user works like that is so that you can edit only part of a user object, which is currently a necessity for profile module.
Having to pass the array is really annoying, especially since you need to call user_save separately with "category" values as well as the array of data you want to save!
All you should really need to do is call a user_save($user) with a fully updated user object (or array ;)).
Profile module knows which fields it is responsible for, I can't see why it needs to rely on a separate edit array and category value to tell it what it already knows based on the {profile_fields} table.
The main trick is that each module that adds data to the user object needs to remember to unset() the values it is responsible for, lest they be serialized into the {user}.data graveyard.
All this code being discussed here is really old and it wouldn't hurt to come up with a more elegant solution. Cheers, Gerhard
participants (4)
-
Earl Miles -
Gerhard Killesreiter -
Nedjo Rogers -
Rowan Kerr