Topic: Something like loadMemberData() but which RETURNS the data

[Yoshi]

Hi!

Sorry if this has been asked before, I'm horrible with searching

Anyway, this has been bothering me for a while now.

SMF has a couple of functions, loadmembercontext and loadmemberdata which does what they say. Though they could have improvements.

For one and the only thing I'm going to talk about, the current features of these functions are WAY too complex.
You have to call then and find a way of grabbing the variables from some variable.
I'd rather, and that's my opinion, see a way of having the function return the data instead. This way, SMF doesn't have to carry all that data in $context or something if it's only used once, plus you can just catch it and done.

What do you guys think?

[Arantor]

Except that it's actually faster to store it in a global variable rather than passing it back and forth, which is why it doesn't.

You do know that loadMemberData actually returns a meaningful value in itself, though, right?

[Yoshi]

Except that it's actually faster to store it in a global variable rather than passing it back and forth, which is why it doesn't.

That's possible, but maybe build a parameter that returns the data, too, AND putting it in a global variable then. Again, this is just my opinion and I'm fine with it when you disregard this.

You do know that loadMemberData actually returns a meaningful value in itself, though, right?

Nope, never really investigated what and how it returns something but I know it doesn't return the member data, lol.

[Arantor]

That's possible, but maybe build a parameter that returns the data, too, AND putting it in a global variable then. Again, this is just my opinion and I'm fine with it when you disregard this.

Yay, let's make it even more complicated. Most people who call it don't understand what the significance of all three existing parameters is, for example, that in most cases it makes extra queries for data you won't need.

I can see why you think it's a good idea, but it really isn't. Apart from the fact you lose the extra data that the current return value is, you end up pushing a lot more data around than you would now, which would be slower and faster.

Why would you return a big, massive array by value (which requires all sorts of memory allocation) when you can just call it from the one place it already is and not cause any more performance issues with it? You wouldn't, basically.

Nope, never really investigated what and how it returns something but I know it doesn't return the member data, lol.

It returns the list of member details it was able to load. So you can push in a list of members and get a list of members that actually exist. Plenty of times that's been useful.

[Yoshi]

That's possible, but maybe build a parameter that returns the data, too, AND putting it in a global variable then. Again, this is just my opinion and I'm fine with it when you disregard this.

Yay, let's make it even more complicated. Most people who call it don't understand what the significance of all three existing parameters is, for example, that in most cases it makes extra queries for data you won't need.

Uh, I was just throwing ideas up there. Nevermind me

I can see why you think it's a good idea, but it really isn't. Apart from the fact you lose the extra data that the current return value is, you end up pushing a lot more data around than you would now, which would be slower and faster.

Right, slower and faster.
Anyway, I guess this may indeed be a performance issue now that I think about it, playing with big arrays.

Why would you return a big, massive array by value (which requires all sorts of memory allocation) when you can just call it from the one place it already is and not cause any more performance issues with it? You wouldn't, basically.

Well, I don't know for the heck of life what place it is put in. It isn't even mentioned in the function database AFAICR.

Nope, never really investigated what and how it returns something but I know it doesn't return the member data, lol.

It returns the list of member details it was able to load. So you can push in a list of members and get a list of members that actually exist. Plenty of times that's been useful.

Oh, that's good to know. I just skipped over the var_dump and found that it didn't include the data I wanted so yeah, lol.

[Arantor]

Right, slower and faster.
Anyway, I guess this may indeed be a performance issue now that I think about it, playing with big arrays.

No, just slower. You still need to push it into global and then clone it to be able to return it.

It might be faster for *you to use* but not for the users of the forum.

Well, I don't know for the heck of life what place it is put in. It isn't even mentioned in the function database AFAICR.

$user_profile contains it.

Also note that loadMemberContext also does something similar; it loads it into $memberContext and returns true so that you know it was able to do so. Much faster than building that array and passing it back as a value.

[Yoshi]

Right, slower and faster.
Anyway, I guess this may indeed be a performance issue now that I think about it, playing with big arrays.

No, just slower. You still need to push it into global and then clone it to be able to return it.

It might be faster for *you to use* but not for the users of the forum.

I was just quoting what you said, lol. Damn should be more clear, being tired isn't going to help much with that.

Well, I don't know for the heck of life what place it is put in. It isn't even mentioned in the function database AFAICR.

$user_profile contains it.

Also note that loadMemberContext also does something similar; it loads it into $memberContext and returns true so that you know it was able to do so. Much faster than building that array and passing it back as a value.

Oh, thanks, that's good to know. I was jiggling around like this lol:

Code: [Select]

loadMemberContext(otherid);
$user = $context['user'];
loadMemberContext(originalid);
Which in the end didn't work, as you may have guessed