NYCPHP Meetup

[Gary Mort]

I am wondering what the reasoning on depreciating this was.

For example:

This is valid:
function foo(&$var)
{
$var++;
}

$a=1;
foo($a);
echo $a; // value is 2

This is depreciated:
function foo($var)
{
$var++;
}

$a=1;
foo(&$a);
echo $a; // value is 2


My own thinking here is that since I am using many open source frameworks,
as the application DEVELOPER I am in the best position to know when I want
to pass a value by reference and when I do not.


For example, if I have a large complex user object, and it may refer to the
current logged in user OR it may refer to another user, I may have an
application level function to grant a user admin authority to the system.

So, we have
$grantUser = $application->getUser();
vs
$grantUser = $application->getUserById($someid);

[or it could be Application::getUser() if we were using static
variables....the process is irrelevant, the point is that you have a user
object, ok?]

So now, I want to make the user an administrator.

$return = Application::setUserRole($grantUser, USER_ADMIN);

As the APPLICATION developer, I know best if I want to have the
$grantUser object
updated with the new levels or not. If I know I am dealing with the current
user, than I want the admin authority to immediately be applied so it will
flow to all future function calls:
$return= Application::setUserRole(&$grantUser, USER_ADMIN);

Wheras if I am dealing with the previous user, I may very well want to keep
the original user to see if any changes where made:
$return = Application::setUserRole($grantUser, USER_ADMIN);

if ($return) {
     // what was the users previous role
     $previousRole = $grantUser->getRole();

          if ($previousRole == USER_ADMIN) {
             echo 'This user already is an Admin!';
          } else {
               echo 'This user was changed from
'.AccessRoles::showDisplay($previousRole).' to an Application Admin.';
          }
}


However, according to the new 5.3 rules, I would actually need to have 2
methods defined in my object, one where I am passing by reference and one
where I am not - because I should not be deciding when to pass by reference
at the time I call the method.

Part of what I like about PHP is that it tends to be very PROGRAMMER
empowering.  Granted, this is what also causes a lot of problems in bad
code.  But it is always up to the programmer what he wants to do.  With this
change, a lot of the rule setting is moved from the programmer to the API
designer.  If I wanted to write Java code, that is what I'd do.

Furthermore, since pass by reference is now exclusively set in the API, to
be safe when using ANY API if I do NOT want to pass by reference, my actual
code should be:
// get my user
$grantUser = $application->getUser();
// assign a working object for the user so my data is not changed
// by some API designers whim
$workUser = $grantUser;

$return= Application::setUserRole($workUser, USER_ADMIN);

This way, just in case $workUser is changed, it will[at the time it is
changed] be cloned and modified, leaving $grantUser as it was when
originally set.  Ok, minor rant, since in the past it was EQUALLY possible
for the API designer and the end programmer to specify this, so I should
have been doing that all along and not trusting the API designer to make
choices I agreed with. :-)

So am I missing something here?  Is there some tremendous benefit to
restricting the end application developer in this manner?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20100702/6fa4b02b/attachment.html>