By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,652 Members | 1,487 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,652 IT Pros & Developers. It's quick & easy.

how does one access global variables when register_globals is off?

P: n/a

If I set a variable at the top of my code like this:

$name = "Lawrence";

It is now a global variable.

If, later on, in a function, I want to do this:

function uppercaseName() {
global $name;
$name = ucfirst($name);
}

Will the global keyword work? If not, where do I find the $name
variable?

Jul 17 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
One quick glance of an experienced eye allowed to understand the blurred
and almost unreadable lk******@geocities.com's handwriting:

If I set a variable at the top of my code like this:

$name = "Lawrence";

It is now a global variable.

If, later on, in a function, I want to do this:

function uppercaseName() {
global $name;
$name = ucfirst($name);
}

Will the global keyword work? If not, where do I find the $name
variable?


AFAIK, register_globals affects $_POST and $_GET vars *only* (if on, it
registers, say, $_POST['myvar'] as a global $myvar). You don't have to
worry about your globals.

Although it is a good habit to always refer to global vars as
$GLOBALS['varname'] (in your example: $GLOBALS['name']) as this gives
you a clear distinction between global and local vars; otherwise you
might get lost somewhere and get misbehaviour that you cannot find the
reason of.

Cheers
Mike
Jul 17 '05 #2

P: n/a
I usually follow your advice about using $GLOBALS['varname'], but my
code broke when I moved to a server with register+globals off, so I
assume some important variables never make it into GLOBALS when
register+globals is off.

Jul 17 '05 #3

P: n/a
In article <d3**********@213-238-64-25.adsl.inetia.pl>, Micha³ Wo¼niak wrote:
One quick glance of an experienced eye allowed to understand the blurred
and almost unreadable lk******@geocities.com's handwriting:

If I set a variable at the top of my code like this:

$name = "Lawrence";

It is now a global variable.

If, later on, in a function, I want to do this:

function uppercaseName() {
global $name;
$name = ucfirst($name);
}

Will the global keyword work? If not, where do I find the $name
variable?

It will work. In fact, this is the a proper way of doing this.

AFAIK, register_globals affects $_POST and $_GET vars *only* (if on, it
registers, say, $_POST['myvar'] as a global $myvar). You don't have to
worry about your globals.


It affects environment variables, cookies and session as well.

http://www.php.net/manual/en/security.globals.php
Jul 17 '05 #4

P: n/a
JDS
On Thu, 14 Apr 2005 01:18:13 -0700, lkrubner wrote:
If, later on, in a function, I want to do this:

function uppercaseName() {
global $name;
$name = ucfirst($name);
}


Honestly, you really never want to do that. I wish I could concisely
explain why, but suffice it to say that using global variables is bad
because:

* it breaks the scope concept of the programming language
* in complex programming projects (and even simple ones) you can clobber
variables and create a real mess
* i'm sure there are other reasons

This is a decent article explaining the problems with globals (in a C
programming context but the concepts apply to PHP):

http://c2.com/cgi/wiki?GlobalVariablesAreBad

Why do you think that register_globals is off by default?

Your function above should take a value as input and return the uppercased
value as output. That is how functions are designed to work. The way you
wrote the function is *very* poor programming practice and continuing to
do that will bite you later. It will. Really.

try this:

function uppercasename($name){
return ucfirst($name);
}

In any case, I suggest using defined constants for things that need to be
global in scope. (Not necessarily appropo for your example).

later...

--
JDS | je*****@example.invalid
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/

Jul 17 '05 #5

P: n/a
In article <pa****************************@example.invalid> , JDS wrote:
On Thu, 14 Apr 2005 01:18:13 -0700, lkrubner wrote:
If, later on, in a function, I want to do this:

function uppercaseName() {
global $name;
$name = ucfirst($name);
}
Honestly, you really never want to do that. I wish I could concisely
explain why, but suffice it to say that using global variables is bad
because:

* it breaks the scope concept of the programming language
* in complex programming projects (and even simple ones) you can clobber
variables and create a real mess
* i'm sure there are other reasons

This is a decent article explaining the problems with globals (in a C
programming context but the concepts apply to PHP):


Every problem requires thinking. You can't simply say it's bad to do
this or that. It's like the goto-hate-movement. Gotos, for example,
are still well used today by programmers who know well how to do it.

[...]
Why do you think that register_globals is off by default?
Because he probably checked the documentation and tested with a
default installation.

http://www.php.net/manual/en/security.globals.php
Your function above should take a value as input and return the uppercased
value as output. That is how functions are designed to work. The way you
wrote the function is *very* poor programming practice and continuing to
do that will bite you later. It will. Really.

try this:

function uppercasename($name){
return ucfirst($name);
}

I agree with you here, but this is just one case.
In any case, I suggest using defined constants for things that need to be
global in scope. (Not necessarily appropo for your example).


What if you want to change them?
Jul 17 '05 #6

P: n/a
JDS
On Thu, 14 Apr 2005 09:47:51 +0000, Daniel C. Bastos wrote:
I agree with you here, but this is just one case.
In any case, I suggest using defined constants for things that need to be
global in scope. (Not necessarily appropo for your example).


What if you want to change them?


Well, okay, so constants are not perfect for everything.

However, (and I am assuming a newbie level programming expertise on the
part of the OP), unless you really know what you are doing, it is bad to
get into the *habit* of using global variables.

I agree that it is not *always* bad to use globals. Any statement with
"always" or "never" in it is almost certainly false. However it is very
bad, IMO, to teach a new programmer to use globals to do everything.
Rules are meant to be broken, but they really shouldn't be broken until
one learns the rules in the first place, and can understand *why* breaking
a rule here or there would work, or *not* work.

I'm basing this on the OP's complete misuse of globals in and out of a
function (his uppercaseName() function example) and additional
misunderstanding of how functions are meant to work.

--
JDS | je*****@example.invalid
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/

Jul 17 '05 #7

P: n/a
In article <pa****************************@example.invalid> , JDS wrote:
On Thu, 14 Apr 2005 09:47:51 +0000, Daniel C. Bastos wrote:
I agree with you here, but this is just one case.
In any case, I suggest using defined constants for things that need to be
global in scope. (Not necessarily appropo for your example).
What if you want to change them?


Well, okay, so constants are not perfect for everything.

However, (and I am assuming a newbie level programming expertise on the
part of the OP), unless you really know what you are doing, it is bad to
get into the *habit* of using global variables.


I disagree with your didacticism. I tell myself to go ahead and try my
own ideas and see if they work well. If they work well, then they work
well. I consider myself unexperienced in programming in general, but I
think I started progressing when I decided to drop all of these
``lessons''. I don't think level of knowledge matters, do you?

I think it's better to think for yourself. Someone tells you ``it's
better to write a function for this one specific case'', you should
think ``Why?'' and see if you can find reasons in favor and against
the statement. I think you truly learn this way.

[...]
I'm basing this on the OP's complete misuse of globals in and out of a
function (his uppercaseName() function example) and additional
misunderstanding of how functions are meant to work.


Your suggestion was good, IMO.
Jul 17 '05 #8

P: n/a
JDS
On Thu, 14 Apr 2005 12:03:08 +0000, Daniel C. Bastos wrote:
I disagree with your didacticism. I tell myself to go ahead and try my
own ideas and see if they work well. If they work well, then they work
well. I consider myself unexperienced in programming in general, but I
think I started progressing when I decided to drop all of these
``lessons''. I don't think level of knowledge matters, do you?

I think it's better to think for yourself. Someone tells you ``it's
better to write a function for this one specific case'', you should
think ``Why?'' and see if you can find reasons in favor and against
the statement. I think you truly learn this way.

[...]


Think for yourself, yes. But there is no point in reinventing the wheel.

I'll take guitar playing as an example. There were several technique
related issues that I actually learned from guitar instructors. Aside
from that, I am completely self taught. The technique issues were
specific things that I would have taken a *very* long time to figure out
myself, and that greatly improved my own technique, and, given long enough
entrenchment, things that would have been very hard for me to un-learn
once I finally came to the realization that my poor, self-taught technique
was the bottleneck preventing me from improving further. (actually, my
self taught technique *is* a bottleneck, still).

In the case of programming, I was being didactic about *technique* issues.
Not *style* issues. There are many tried and true reasons why globals are
not usually the best solution for a problem -- and it often does pay to
learn from people who have tread there in the past.

I was not suggesting a style or preference as better than another. I
wouldn't do that (well, I try not to), and I think that if you learn
enough of the "why" behind my blanket "don't do that" statements against
globals, you would see the difference. Maybe you do.

--
JDS | je*****@example.invalid
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/

Jul 17 '05 #9

P: n/a
I think we are getting OT here. The question was "should it work" and the
answer is "yes", unless of course $name is actually a... registered
global. :)
I think a good idea would be to show how the $name was originally
declared. And changing $name to $GLOBALS['name'] everywhere in the code.
If such a change will break the code => $name is most probably a
registered global (e.g. from POST or GET) => it will NOT work with
register_globals off, and it is a great example why shoul it be always
of and why shoul one use $GLOBALS['somevar'], $_POST['someothervar'] and
so on instead of $somevar and $someothervar.

Cheers
Mike
Jul 17 '05 #10

P: n/a
In article <pa****************************@example.invalid> , JDS wrote:
On Thu, 14 Apr 2005 12:03:08 +0000, Daniel C. Bastos wrote:
I disagree with your didacticism. I tell myself to go ahead and try my
own ideas and see if they work well. If they work well, then they work
well. I consider myself unexperienced in programming in general, but I
think I started progressing when I decided to drop all of these
``lessons''. I don't think level of knowledge matters, do you?

I think it's better to think for yourself. Someone tells you ``it's
better to write a function for this one specific case'', you should
think ``Why?'' and see if you can find reasons in favor and against
the statement. I think you truly learn this way.

[...]
Think for yourself, yes. But there is no point in reinventing the wheel.


I probably agree with you here. I say ``probablly'' because
reinventing the wheel is a bit necessary sometimes for learning. But
``reinventing the wheel'' is a vague expression in this context. Let
me give you an example.

If I want to learn how ``insertion sort'' works, I will read
publications about it and attempt to write it from scratch as if I was
inventing it myself, so I'm re-doing it, copying it, but trying to
make sure that I understand every step of it.

By no means I imply that this is the best method. I do it this way
many times because the knowledge I have tells me so and I'm satisfied
so far.

But you see, this isn't exactly reinventing the wheel because I am
only following someone's steps just to try to see what she saw. And
this is a didactic method I use myself. IMO, this is different from
writing insertion sort in a different way (reinventing the wheel).

[...]
In the case of programming, I was being didactic about *technique* issues.
Not *style* issues. There are many tried and true reasons why globals are
not usually the best solution for a problem -- and it often does pay to
learn from people who have tread there in the past.

I was not suggesting a style or preference as better than another. I
wouldn't do that (well, I try not to), and I think that if you learn
enough of the "why" behind my blanket "don't do that" statements against
globals, you would see the difference. Maybe you do.


What I see is that, specially in PHP, many times global variables are
really not the way to go. I agree with that. I rarely use global
variables in PHP, but I do sometimes, when I need a global
variable. :D Now, you could argue on ``Do you really need it when you
think you need it?'' and we would need specific cases.

Jul 17 '05 #11

P: n/a
In article <d3**********@213-238-64-25.adsl.inetia.pl>, Micha³ Wo¼niak wrote:
I think we are getting OT here. The question was "should it work" and the
answer is "yes", unless of course $name is actually a... registered
global. :)


Agreed.

[...]
Jul 17 '05 #12

P: n/a
One quick glance of an experienced eye allowed to understand the blurred
and almost unreadable Daniel C. Bastos's handwriting:
In article <pa****************************@example.invalid> , JDS wrote:
On Thu, 14 Apr 2005 12:03:08 +0000, Daniel C. Bastos wrote:
I disagree with your didacticism. I tell myself to go ahead and try
my own ideas and see if they work well. If they work well, then they
work well. I consider myself unexperienced in programming in general,
but I think I started progressing when I decided to drop all of these
``lessons''. I don't think level of knowledge matters, do you?

I think it's better to think for yourself. Someone tells you ``it's
better to write a function for this one specific case'', you should
think ``Why?'' and see if you can find reasons in favor and against
the statement. I think you truly learn this way.

[...]
Think for yourself, yes. But there is no point in reinventing the
wheel.


I probably agree with you here. I say ``probablly'' because
reinventing the wheel is a bit necessary sometimes for learning. But
``reinventing the wheel'' is a vague expression in this context. Let
me give you an example.

If I want to learn how ``insertion sort'' works, I will read
publications about it and attempt to write it from scratch as if I was
inventing it myself, so I'm re-doing it, copying it, but trying to
make sure that I understand every step of it.

By no means I imply that this is the best method. I do it this way
many times because the knowledge I have tells me so and I'm satisfied
so far.

But you see, this isn't exactly reinventing the wheel because I am
only following someone's steps just to try to see what she saw. And
this is a didactic method I use myself. IMO, this is different from
writing insertion sort in a different way (reinventing the wheel).


Agreed. I wrote an authentication through SessionID myself in PHP just to
know how it is being done. I could use SESSIONS, but I preferred to
write it myself the first time.
[...]
In the case of programming, I was being didactic about *technique*
issues.
Not *style* issues. There are many tried and true reasons why globals
are not usually the best solution for a problem -- and it often does
pay to learn from people who have tread there in the past.

I was not suggesting a style or preference as better than another. I
wouldn't do that (well, I try not to), and I think that if you learn
enough of the "why" behind my blanket "don't do that" statements
against
globals, you would see the difference. Maybe you do.


What I see is that, specially in PHP, many times global variables are
really not the way to go. I agree with that. I rarely use global
variables in PHP, but I do sometimes, when I need a global
variable. :D Now, you could argue on ``Do you really need it when you
think you need it?'' and we would need specific cases.


If I have a value that has to be accessible to all the parts of my script
and has to be possible to modify (which is VERY rare), I will use
globals. Globals are a tool, and like any tool they might be misused.
But, like every tool, they ARE useful sometimes.

Cheers
Mike
Jul 17 '05 #13

P: n/a
I noticed that Message-ID:
<pa****************************@example.invalid> from JDS contained the
following:
I was not suggesting a style or preference as better than another. I
wouldn't do that (well, I try not to), and I think that if you learn
enough of the "why" behind my blanket "don't do that" statements against
globals, you would see the difference. Maybe you do.


I recently wrote a function to add drop shadows to images. The function
uses three image files to create the drop shadows and I define absolute
paths to these as constants.

Is this good or bad use of constsnts/globals?
//original size of shadow images is shown below
define("BOTTOM_SHADOW","/images/bottom_white.jpg");
//387x19
define("RIGHT_SHADOW","/images/right_white.jpg");
//280x19
define("CORNER_SHADOW","/images/corner_white.jpg");
//19x19

function ds($image,$dsw,$alt){
//first check that file exists
if(file_exists($image)){
//create an image from the file
$img=ImageCreateFromJpeg($image);
//print containing <div> using image width plus shadow width
print "<div style='width:
".(imagesx($img)+$dsw)."px;margin:0px'>\n";
//print image
print "<img style='float: left;' src='$image'
height='".imagesy($img)."' width='".imagesx($img)."'alt='$alt'>\n";
//print right shadow using image sizes
print "<img style='float: left;'
src='".RIGHT_SHADOW."'height='".imagesy($img)."'wi dth='$dsw'alt=''>\n";
//print bottom shadow using image sizes
print"<img style='float: left;'
src='".BOTTOM_SHADOW."'width='".imagesx($img)."'he ight='$dsw'alt=''>\n";
//print corner shadow using image sizes
print "<img style='float: left;'
src='".CORNER_SHADOW."'height='$dsw'width='$dsw'al t=''>\n";
//print closing </div>
print "</div>\n";
}
}

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
Jul 17 '05 #14

P: n/a
JDS
On Fri, 15 Apr 2005 08:03:03 +0100, Geoff Berrow wrote:
Is this good or bad use of constsnts/globals?


Personally, I think defining constants is the way to go for your example.

--
JDS | je*****@go.away.com
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/

Jul 17 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.