uh oh, I defined a resoruce

Eric Butera wrote:
> Haha. Thank you for all that insightful research. Seriously though,
> using globals you might already be in hell! =\

IMHO global variables are evil in the same way that register_globals
were. Despite everything you've probably heard it is actually possible
to create a secure site with register_globals enabled, but it needs to
be done with due care and attention. The same goes for globals. They are
not inherently evil but they are easily abused so you need to be careful
when you use them.

-Stut

--
http://stut.net/

On Jan 10, 2008 4:00 PM, Stut <stuttle@gmail.com> wrote:
> Eric Butera wrote:
> > Haha. Thank you for all that insightful research. Seriously though,
> > using globals you might already be in hell! =\
>
> IMHO global variables are evil in the same way that register_globals
> were. Despite everything you've probably heard it is actually possible
> to create a secure site with register_globals enabled, but it needs to
> be done with due care and attention. The same goes for globals. They are
> not inherently evil but they are easily abused so you need to be careful
> when you use them.
>
> -Stut
>
> --
> http://stut.net/
>

Stut,

That is all well and fine and I agree with you on some level. The
only problem is that this is the php-general list and as such I try
and put red flags on things to help others realize sooner than I did
the pro/con list of things.

Register globals makes working with request data extremely easy. At
the same time it also makes it where GPC collisions and whatnot can
really burn you in the end. For the overwhelming majority of users it
causes more problems than it solves which is why it is going away.....
someday.

Eric Butera schreef:
> On Jan 10, 2008 4:00 PM, Stut <stuttle@gmail.com> wrote:
>> Eric Butera wrote:
>>> Haha. Thank you for all that insightful research. Seriously though,
>>> using globals you might already be in hell! =\
>> IMHO global variables are evil in the same way that register_globals
>> were. Despite everything you've probably heard it is actually possible
>> to create a secure site with register_globals enabled, but it needs to
>> be done with due care and attention. The same goes for globals. They are
>> not inherently evil but they are easily abused so you need to be careful
>> when you use them.
>>
>> -Stut
>>
>> --
>> http://stut.net/
>>
>
> Stut,
>
> That is all well and fine and I agree with you on some level. The
> only problem is that this is the php-general list and as such I try
> and put red flags on things to help others realize sooner than I did
> the pro/con list of things.

if you can follow Stut's advice regarding globals then it's a good thing,
if you're very good at what you do you'll know when it's *acceptable* to
take a little short cut and use a global (most people have one or two those
little projects that have to be up and running in no time where a global
or two helps shave some undesired time and complexity from the project)

> Register globals makes working with request data extremely easy.

really? if you see $_POST['foo'] you know where it came from,
if you see $foo you can't be sure it's a request var ... in the most
extreme case it could be a var declared in an auto_prepend_file.

of course if you know absolutely nothing about php it make's it easier - but
in the long run (same the 5 or 10 minutes it takes to read up on request superglobals)
it's an accident waiting to happen.

> At
> the same time it also makes it where GPC collisions and whatnot can
> really burn you in the end. For the overwhelming majority of users it
> causes more problems than it solves which is why it is going away.....
> someday.



>

On Jan 10, 2008 4:41 PM, Jochem Maas <jochem@iamjochem.com> wrote:
> Eric Butera schreef:
> > On Jan 10, 2008 4:00 PM, Stut <stuttle@gmail.com> wrote:
> >> Eric Butera wrote:
> >>> Haha. Thank you for all that insightful research. Seriously though,
> >>> using globals you might already be in hell! =\
> >> IMHO global variables are evil in the same way that register_globals
> >> were. Despite everything you've probably heard it is actually possible
> >> to create a secure site with register_globals enabled, but it needs to
> >> be done with due care and attention. The same goes for globals. They are
> >> not inherently evil but they are easily abused so you need to be careful
> >> when you use them.
> >>
> >> -Stut
> >>
> >> --
> >> http://stut.net/
> >>
> >
> > Stut,
> >
> > That is all well and fine and I agree with you on some level. The
> > only problem is that this is the php-general list and as such I try
> > and put red flags on things to help others realize sooner than I did
> > the pro/con list of things.
>
> if you can follow Stut's advice regarding globals then it's a good thing,
> if you're very good at what you do you'll know when it's *acceptable* to
> take a little short cut and use a global (most people have one or two those
> little projects that have to be up and running in no time where a global
> or two helps shave some undesired time and complexity from the project)
>
> > Register globals makes working with request data extremely easy.
>
> really? if you see $_POST['foo'] you know where it came from,
> if you see $foo you can't be sure it's a request var ... in the most
> extreme case it could be a var declared in an auto_prepend_file.

$foo is less characters than $_POST['foo'], so yes it is easier to
type. I didn't say it was right, I just said it made it easier.
Anytime you see id= in a url or name= in a form just throw a $ sign in
front of it and you're in business. I guarantee you a starting user
will get that faster than $_GET and $_POST. Someone just coming at
this isn't going to understand the difference between request types or
the fact that a form can even have both of them in the method. :)

>
> of course if you know absolutely nothing about php it make's it easier - but
> in the long run (same the 5 or 10 minutes it takes to read up on request superglobals)
> it's an accident waiting to happen.

I never said it wasn't.

>
>
> > At
> > the same time it also makes it where GPC collisions and whatnot can
> > really burn you in the end. For the overwhelming majority of users it
> > causes more problems than it solves which is why it is going away.....
> > someday.
>
>
>
> >
>
>

>> While "global variables are good" in quotes did not return any results
>> from Google, "global variables are evil" in quotes only returned a result
>> set of 4:
>>
>> Results *1* - *4* of *4* for *" global<http://www.google.com/url?sa=X&oi=dict&ei=-nyGR539MKjIgQT1hKC7Bg&sig2=Gorx1ErPpjplcNDVa0qb6g& q=http://www.answers.com/global%26r%3D67&usg=AFQjCNFszs4YfNg7ok3-m08IgyrhO5EAsQ>
>> variable<http://www.google.com/url?sa=X&oi=dict&ei=-nyGR539MKjIgQT1hKC7Bg&sig2=vCOY79teeScIcrxuvb6k3g& q=http://www.answers.com/variable%26r%3D67&usg=AFQjCNEzQBZwfNnJ4pr1pnYOXYtt JJNkvg>are
>> evil<http://www.google.com/url?sa=X&oi=dict&ei=-nyGR539MKjIgQT1hKC7Bg&sig2=eh8-cXxXIwGuHRJhXG2REQ&q=http://www.answers.com/evil%26r%3D67&usg=AFQjCNHcgNJwcVKoYcSB_Ks5OMr4LnAX Ww>
>> "*
>> **
>> Hardly an overwhelming argument by using search results as a measure.
>>
>> David
>>
>>
>
> Nevermind. I forgot the 's'.
>
> Once again:
>
> Personalized Results *1* - *8* of *8* for
> *"global<http://www.google.com/url?sa=X&oi=dict&ei=joCGR9SjMp2wgATIv4HWBg&sig2=RN nAskxl87Jpwe85XDzyvg&q=http://www.answers.com/global%26r%3D67&usg=AFQjCNFkKRqMEPNyoEfdOeatXZo5_5 1d5Q>
> variables<http://www.google.com/url?sa=X&oi=dict&ei=joCGR9SjMp2wgATIv4HWBg&sig2=b_ YKTOej3C0R3RD0QrZUwA&q=http://www.answers.com/variables%26r%3D67&usg=AFQjCNGXzEwYW9a5HoADskUH1aT T5OIvsg>are
> good<http://www.google.com/url?sa=X&oi=dict&ei=joCGR9SjMp2wgATIv4HWBg&sig2=L-Je5IAp1doAPCeTovvqwA&q=http://www.answers.com/good%26r%3D67&usg=AFQjCNG9Bm-38XQxaR5w7aHA_cDvLT1nSw>
> "*. (*0.17* seconds)
>
> Personalized Results *1* - *10* of about *136* for
> *"global<http://www.google.com/url?sa=X&oi=dict&ei=xYCGR-TiK4fcgASYpOi2Bg&sig2=ntdSUwxo_P-rplOA3PKNrw&q=http://www.answers.com/global%26r%3D67&usg=AFQjCNE2teAhA638GVYsBxeBxb9z0i Yi5A>
> variables<http://www.google.com/url?sa=X&oi=dict&ei=xYCGR-TiK4fcgASYpOi2Bg&sig2=zCmKFYtnVoOQlWKrXcLqdw&q=htt p://www.answers.com/variables%26r%3D67&usg=AFQjCNEEdMRqxKMgkWXftVCWfE4 kZr98jg>are
> evil<http://www.google.com/url?sa=X&oi=dict&ei=xYCGR-TiK4fcgASYpOi2Bg&sig2=HxVB1-BREdrmjuSHo6E9jQ&q=http://www.answers.com/evil%26r%3D67&usg=AFQjCNErEUXMUFMcXbjo95hRT2t8pzkI Sg>
> "*. (*0.07* seconds
>
> Ok. So those of us who use globals are 17 time more likely to end up in
> hell.
>
> I can live with those odds.
>
> David

God, I'm glad you're not in charge of decision-making on any issues that
affect me :P
- Naz.

On 1/13/08, Naz Gassiep <naz@mira.net> wrote:
>
>
> >> While "global variables are good" in quotes did not return any results
> >> from Google, "global variables are evil" in quotes only returned a
> result
> >> set of 4:
> >>
> >> Results *1* - *4* of *4* for *" global<
> http://www.google.com/url?sa=X&oi=di...m08IgyrhO5EAsQ
> >
> >> variable<
> http://www.google.com/url?sa=X&oi=di...pnYOXYttJJNkvg
> >are
> >> evil<
> http://www.google.com/url?sa=X&oi=di..._Ks5OMr4LnAXWw
> >
> >> "*
> >> **
> >> Hardly an overwhelming argument by using search results as a measure.
> >>
> >> David
> >>
> >>
> >
> > Nevermind. I forgot the 's'.
> >
> > Once again:
> >
> > Personalized Results *1* - *8* of *8* for
> > *"global<
> http://www.google.com/url?sa=X&oi=di...OeatXZo5_51d5Q
> >
> > variables<
> http://www.google.com/url?sa=X&oi=di...skUH1aTT5OIvsg
> >are
> > good<
> http://www.google.com/url?sa=X&oi=di...7aHA_cDvLT1nSw
> >
> > "*. (*0.17* seconds)
> >
> > Personalized Results *1* - *10* of about *136* for
> > *"global<
> http://www.google.com/url?sa=X&oi=di...BxeBxb9z0iYi5A
> >
> > variables<
> http://www.google.com/url?sa=X&oi=di...tVCWfE4kZr98jg
> >are
> > evil<
> http://www.google.com/url?sa=X&oi=di...95hRT2t8pzkISg
> >
> > "*. (*0.07* seconds
> >
> > Ok. So those of us who use globals are 17 time more likely to end up in
> > hell.
> >
> > I can live with those odds.
> >
> > David
>
> God, I'm glad you're not in charge of decision-making on any issues that
> affect me :P
> - Naz.
>

How kind of you to clarify your position, Naz. ;~)

David

the 2 problems that globals introduce are

1. namespace collisions
2. point of origin problem

where a namespace collision is the inconsistent use of a global
variable within an application
eg.
// one point in the application
$GLOBALS['curUser'] = array('username' => 'bob', 'userId' => 5);

// another point in the application
$GLOBALS['curUser'] = new stdClass();
$GLOBALS['curUser']->username = 'bob';
$GLOBALS['curUser']->userId = 5;

and what im calling the 'point of origin' problem, is the ambiguity
introduced by global variables. when reading through the code of an
application and you encounter the use of a global variable, where was
that variable set? if not in the same file, then youll have to start
looking. you may not even be able to determine where the value is
getting set by looking through the code, that is, you might have to analyze
the runtime behavior of the application. and with the $GLOBALS array, this
can be cumbersome because there is no way (that i know of) to add implicit
logging to setting of values within.

now, whether you or your team or business or w/e will have to deal with
these
problems depends on what sort of conventions, if any, are used to work with
globals (or whether theyre used at all ;)).

to make them work in a team environment you should have some external
documentation
that establishes clear usage guidelines and outlines the purpose (or
declares 'namespaces')
within the $GLOBALS array. so you might say "$GLOBALS['user'] is designated
to contain
user data, which will be a record from the users table in our database". it
will be an array.
at that point if someone uses $GLOBALS['user'] for something else, or
changes its data type
or something, you can say, well youve violated our convention here so youll
have to clean that up.

there is the issue of working with code from other parties and this is where
things
can still get messy. say that you have your conventions and everything is
hunky-dory; then you
decide to use some third party code, and it uses one of your global
'namespaces'.
so for example you get some third party code and within it, for whatever
reason $GLOBALS['user']
(referenced earlier) is being read or set. well if you want to use that
code, youll have to refactor
either yours, or theirs.

object oriented development helps with some of these problems, but it is not
by itself a silver bullet.
for example with singleton
http://www.phppatterns.com/doku.php/...gleton_pattern
problems 1, and 2 above are still relevant. php is introducing namespaces
soon enough, but prior
to those class name collisions are generally resolved in php by prefixing a
class name
eg.
class User {}
becomes
class MyBiz__User {}

problem 2 though is relevant depending on what the singleton is used for.
suppose it only contains
2 values, a reference to itself and one datum, which is set in the private
constructor (or another private
method invoked as part of the constructor). this is the most trivial case
and it is not really subject to
the problem. however, if a singleton were to have getter and setter methods
problem number 2 above
can occur. the good news here is that since singleton is a class you write,
adding logging is trivial
so you should be able to track down those spurious cases where a value is
set in one portion of the
application and read in another.

i happen to know that facebook uses globals, and i just thought i would
mention it as a 'successful'
yet perhaps 'code not so great' example of a large application using
globals.

if you are to use globals, then establish conventions.
the worst stuff i have ever seen is use of other superglobal arrays for the
same purpose as what the
$GLOBALS array is intended to be.
eg.
// one part of the application
// NOTE: this value did not orginate from the request
$_POST['someVal'] = 5;

// later in the application
$myVar = $_POST['someVal'];

that is just plain bad if you ask me (and they didnt even put the note!).

-nathan

On 1/13/08, Nathan Nobbe <quickshiftin@gmail.com> wrote:
>
> the 2 problems that globals introduce are
>
> 1. namespace collisions
> 2. point of origin problem
>
> where a namespace collision is the inconsistent use of a global
> variable within an application
> eg.
> // one point in the application
> $GLOBALS['curUser'] = array('username' => 'bob', 'userId' => 5);
>
> // another point in the application
> $GLOBALS['curUser'] = new stdClass();
> $GLOBALS['curUser']->username = 'bob';
> $GLOBALS['curUser']->userId = 5;
>
> and what im calling the 'point of origin' problem, is the ambiguity
> introduced by global variables. when reading through the code of an
> application and you encounter the use of a global variable, where was
> that variable set? if not in the same file, then youll have to start
> looking. you may not even be able to determine where the value is
> getting set by looking through the code, that is, you might have to
> analyze
> the runtime behavior of the application. and with the $GLOBALS array,
> this
> can be cumbersome because there is no way (that i know of) to add implicit
> logging to setting of values within.
>
> now, whether you or your team or business or w/e will have to deal with
> these
> problems depends on what sort of conventions, if any, are used to work
> with
> globals (or whether theyre used at all ;)).
>
> to make them work in a team environment you should have some external
> documentation
> that establishes clear usage guidelines and outlines the purpose (or
> declares 'namespaces')
> within the $GLOBALS array. so you might say "$GLOBALS['user'] is
> designated to contain
> user data, which will be a record from the users table in our database".
> it will be an array.
> at that point if someone uses $GLOBALS['user'] for something else, or
> changes its data type
> or something, you can say, well youve violated our convention here so
> youll have to clean that up.
>
> there is the issue of working with code from other parties and this is
> where things
> can still get messy. say that you have your conventions and everything is
> hunky-dory; then you
> decide to use some third party code, and it uses one of your global
> 'namespaces'.
> so for example you get some third party code and within it, for whatever
> reason $GLOBALS['user']
> (referenced earlier) is being read or set. well if you want to use that
> code, youll have to refactor
> either yours, or theirs.
>
> object oriented development helps with some of these problems, but it is
> not by itself a silver bullet.
> for example with singleton
> http://www.phppatterns.com/doku.php/...gleton_pattern
>
> problems 1, and 2 above are still relevant. php is introducing namespaces
> soon enough, but prior
> to those class name collisions are generally resolved in php by prefixing
> a class name
> eg.
> class User {}
> becomes
> class MyBiz__User {}
>
> problem 2 though is relevant depending on what the singleton is used for.
> suppose it only contains
> 2 values, a reference to itself and one datum, which is set in the private
> constructor (or another private
> method invoked as part of the constructor). this is the most trivial case
> and it is not really subject to
> the problem. however, if a singleton were to have getter and setter
> methods problem number 2 above
> can occur. the good news here is that since singleton is a class you
> write, adding logging is trivial
> so you should be able to track down those spurious cases where a value is
> set in one portion of the
> application and read in another.
>
> i happen to know that facebook uses globals, and i just thought i would
> mention it as a 'successful'
> yet perhaps 'code not so great' example of a large application using
> globals.
>
> if you are to use globals, then establish conventions.
> the worst stuff i have ever seen is use of other superglobal arrays for
> the same purpose as what the
> $GLOBALS array is intended to be.
> eg.
> // one part of the application
> // NOTE: this value did not orginate from the request
> $_POST['someVal'] = 5;
>
> // later in the application
> $myVar = $_POST['someVal'];
>
> that is just plain bad if you ask me (and they didnt even put the note!).
>
> -nathan
>


A very cogent and detailed assessment of the issues, Nathan, and I
appreciate the time and thoughtfulness involved in writing your response.

My stance concerning globals is that, on PHP projects anyway, I work alone,
use longish and very descriptive variable names, and most always only use
globals for static data needed for calculations of some kind. But I
certainly appreciate that in a team environment and when working on very
large projects, the odds of globals usage, especially without documentation
and adherence to a standard, can lead to the problems described above.

In general, I agree with Stut's response delineated earlier in this thread,
that a careful and circumscribed use of globals has a place in PHP
programming.

David

On Jan 13, 2008 12:14 PM, David Giragosian <dgiragosian@gmail.com> wrote:

> In general, I agree with Stut's response delineated earlier in this
> thread,
> that a careful and circumscribed use of globals has a place in PHP
> programming.


agreed.

-nathan