Make the API into a class. I will do this, just give me the ok...

You realize that $user is a global, and if it is not the currently logged in user, then we have far more serious issues than just blocks in userpoints.

Also, arg() is not the only means of passing things to the API. The $params array can have an element like this:

$param = array(
  'uid' => 5,
  'points' => 1001,
  ...
);

So, it is not dependent on $user or arg().

For panels, if you are listing points for more than one users, then you have to know the user IDs passed for each user, and go and call the API several times. If there are N users, you have to call it N times. There is no way around that.

I see benefits in making it a class, but the examples you cited are not good use cases. I don't want OOP for the sake of OOP.

But, go ahead and try to convince me ... I am willing to listen.

What we are doing is simply displaying the points for one user.

Then all you need is to do this:

$uid = whatever_way_you_want_to_get_it();  // perhaps $

$points = userpoints_get_current_points($uid);

print $points;

Can't be simpler than the above, and will work anywhere in your code.

Whether OOP or not, you have to pass the uid somehow.

I don't see how OOP will prevent knowing which user's uid you are at, so you can show their points.

My problem is that after we are done, we have to reset this back to the uid we started with (if we had access which we don't). That would then mean that we would have to call the API unnecessarily, on data that we dont have. In our case /user/arg(1) is in fact the uid. So we are all set here. This is not a global panels issue, this is specific to advanced profiles and the use of panels to over-ride the user/ directory. What we need more developers to do is what you already did, which was to provide a variable for the user ID we need.

I don't understand what you mean by "after we are done we have to reset this back"? What is it that you have to reset and reset it to what?

You need to get the points for said user somehow. If you want to save it somewhere, create a static variable (array) and stick it in there.

static $s;
$s[$uid] = $points;

You now have an array with values that you retrieved in the past.

array(
  3 => 50,
  17 => 7,
  128 => -5,
);

As far as OOP for OOP. Well unless there is something wrong with PHP, OOP is always better then module code, and scales better with additional benefits.

Well, I disagree somewhat here, but that is a procedural vs. OOP debate, and mostly about dogma, not merits for the problem at hand.

What we are doing is simply displaying the points for one user.

As kbahey said does userpoints_get_current_points($uid, $tid) do what you need it to do?

My problem is that after we are done, we have to reset this back to the uid we started with (if we had access which we don't).

Can you please elaborate on this? In display the user are you doing a user_load for the profile? Are you saying that we should attach something to the user object?

As far as OOP for OOP. Well unless there is something wrong with PHP, OOP is always better then module code, and scales better with additional benefits. But that is for you to decide. I, and Michelle, would really like your help getting a panel that shows some nice data on the user's points and also be able to transfer date (I know this is part of the expansion). It is a nice module you have, and the coding is far superior to some of that Ive seen.

What is this panel that you speak of? Can you elaborate on this? I know its a custom panel but I'm curious as to how exactly this module can help out your work.
I'm also confused as to what is part of the expansion? Are you referring to user2user points in the contributed modules?

Thanks for the complement about the coding.

It would also be nice to develop a help page based on the database settings within your application.

ya there are a lot of areas where documentation would be nice but there are only so many hours in a day. To be honest I'd love to see you spend the time you would've spent rewriting this module into writing a page on the DB documentation. ALL of the data about the DB is in the issue's queue its definitely be hashed and rehashed out... yes a handbook page would be lovely, fully agree with you but I've already spent too much time responding here to spend more time over there ;)

also a theming page would be nice if you've got the time ;) he he, I gotta try.

Non-OOP requires me to figure out where these settings are in the database and access them.

eh even if it were 100% OOP you'd still have to figure out the DB because no object responds back with "Well we decided to use an int vs. a float or double because of x, y, z" so you're still left with questions. But IMHO the point of an API is that a developer doesn't need to know about the underlying technology (in this case the DB). They need something quick and easy to use; which I think is what we've accomplished. For example: You don't need to know that the userpoints table is a caching table and the userpoints_txn is a transaction table in order to use userpoints_get_currentpoints() or, to add/subtract points, you call userpoints_userpointsapi($points or $param). We're not asking people (if fact we're specifically requesting that people never, never ever as in never ever ever) query the DB directly, use the API it'll do the hard work for you. If you use the API the data structure can change but it won't break your code and you should never see a difference.

As you can see I am a huge OOP fanatic, so I guess you can get more for the advantages of OOP through reading about the reasoning behind the methodology. I am sure you have done that, but I know that they can sell it better then I can. Anyways, Objects rock when you work with others code:)

Hey we all have our opinions and that's awesome.

However I would really, really, really love to see the time and energy you would have put into rebuilding this module into an object into helping us fight the bigger battles of the module. I would like the moderation table/form completely redesigned to be more efficient and there is room to add newer blocks. We also need help with upgrading the contributed modules up to 3 and with an ecommerce upgrade.

There is a lot of work to be done and a lot of improvements we'd like to do. Personally I wouldn't want to simply change the code to an object for the sake of doing it I'd rather focus on items that will really help people out.

IMHO the API is pretty well documented its not perfect but its exists and has all the necessary pieces.