[mailto:p...@hristov.com]
Sent: 09 December 2010 10:14
To: PHP Internals List
Subject: [PHP-DEV] Deprecating global + $GLOBALS, making $_REQUEST, $_GET,
$_POST read-only
Hi guys,
the topic says most of it. What do you think about deprecating the
global keyword and $GLOBALS with it? Together
-Original Message-
From: Andrey Hristov [mailto:p...@hristov.com]
James Butler wrote:
+1 million because GLOBAL scope is horrid (generally) and is thoroughly
abused
-1 million because it will be the most horrific BC break since time began
and I imagine it will break so much code
James Butler wrote:
-Original Message-
From: Andrey Hristov [mailto:p...@hristov.com]
James Butler wrote:
+1 million because GLOBAL scope is horrid (generally) and is thoroughly abused
-1 million because it will be the most horrific BC break since time began and I
imagine it will
On Thu, Dec 9, 2010 at 2:31 AM, James Butler
james.but...@edigitalresearch.com wrote:
Sorry, I wasn't being very clear there, what I really meant to say was will
there be the will to remove it considering the effects.
I suppose INI is enough to allow it to be easily changed, but would it ever
On Thu, Dec 9, 2010 at 2:38 AM, Andrey Hristov p...@hristov.com wrote:
Yes, as the documentation will mention how to do it, for old applications.
For new apps it is easy - pass all the information you need as parameter to
the function. It works in other languages, why shouldn't it work for
2010/12/9 Andrey Hristov p...@hristov.com
Reindl Harald wrote:
Please do not
global + GLOBALS can be used in so many ways and you would break
200.000 LOC only here which is running with reporting E_STRICT
in a production environment
what happened after register_globals was introduced
Michael Shadle wrote:
On Thu, Dec 9, 2010 at 2:38 AM, Andrey Hristov p...@hristov.com wrote:
Yes, as the documentation will mention how to do it, for old applications.
For new apps it is easy - pass all the information you need as parameter to
the function. It works in other languages, why
Eloy Bote Falcon wrote:
2010/12/9 Andrey Hristov p...@hristov.com
Reindl Harald wrote:
Please do not
global + GLOBALS can be used in so many ways and you would break
200.000 LOC only here which is running with reporting E_STRICT
in a production environment
what happened after
On Thu, 9 Dec 2010, Andrey Hristov wrote:
the topic says most of it. What do you think about deprecating the global
keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and
$_POST read-only as they should be used only to read-only anyway.
No thanks.
Derick
--
Derick Rethans wrote:
On Thu, 9 Dec 2010, Andrey Hristov wrote:
the topic says most of it. What do you think about deprecating the global
keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and
$_POST read-only as they should be used only to read-only anyway.
No thanks.
On Thu, Dec 09, 2010 at 11:53:08AM +0100, Andrey Hristov wrote:
Is copying the POST variables into another variables best practice (like a
manual register_globals)? In the global scope of the application I think
it's cleaner to work with $_POST to overwrite the values than copying the
items
Alain Williams wrote:
On Thu, Dec 09, 2010 at 11:53:08AM +0100, Andrey Hristov wrote:
Is copying the POST variables into another variables best practice (like a
manual register_globals)? In the global scope of the application I think
it's cleaner to work with $_POST to overwrite the values
hi,
As far as I remember we discussed that already back to the phpI don't
mention it discussions. It was not accepted because of the little
gains in regard to the major BC breaks.
However I would prefer, as far as it is technically possible,
deprecate their usage (notices/warnings) and promote
On Thu, Dec 9, 2010 at 11:14 AM, Andrey Hristov p...@hristov.com wrote:
Hi guys,
the topic says most of it. What do you think about deprecating the global
keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and
$_POST read-only as they should be used only to read-only
On Thu, Dec 9, 2010 at 12:15 PM, Pierre Joye pierre@gmail.com wrote:
hi,
As far as I remember we discussed that already back to the phpI don't
mention it discussions. It was not accepted because of the little
gains in regard to the major BC breaks.
However I would prefer, as far as it
On Dec 9, 2010, at 3:34, Ferenc Kovacs i...@tyrael.hu wrote:
On Thu, Dec 9, 2010 at 12:15 PM, Pierre Joye pierre@gmail.com wrote:
hi,
As far as I remember we discussed that already back to the phpI don't
mention it discussions. It was not accepted because of the little
gains in
Ferenc Kovacs wrote:
On Thu, Dec 9, 2010 at 11:14 AM, Andrey Hristov p...@hristov.com
mailto:p...@hristov.com wrote:
 Hi guys,
the topic says most of it. What do you think about deprecating the
global keyword and $GLOBALS with it? Together with this making
$_REQUEST, $_GET
On Thu, Dec 9, 2010 at 5:14 AM, Andrey Hristov p...@hristov.com wrote:
Hi guys,
the topic says most of it. What do you think about deprecating the global
keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and
$_POST read-only as they should be used only to read-only
-Original Message-
From: Ilia Alshanetsky [mailto:i...@prohost.org]
On Thu, Dec 9, 2010 at 5:14 AM, Andrey Hristov p...@hristov.com wrote:
Hi guys,
the topic says most of it. What do you think about deprecating the global
keyword and $GLOBALS with it? Together with this making
On Thu, Dec 09, 2010 at 01:15:41PM +0100, Andrey Hristov wrote:
no, you got me wrong. I will repeat - global variables won't cease to
exist, but $GLOBALS and global as means to access them should be
removed. If a function needs data it should get it passed to it.
By large yes, but in
On 9 December 2010 18:14, Andrey Hristov p...@hristov.com wrote:
the topic says most of it. What do you think about deprecating the global
keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and
$_POST read-only as they should be used only to read-only anyway.
-1 here. No
Adam Harvey wrote:
On 9 December 2010 18:14, Andrey Hristov p...@hristov.com wrote:
the topic says most of it. What do you think about deprecating the global
keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and
$_POST read-only as they should be used only to read-only
On 12/9/10 4:46 AM, Andrey Hristov wrote:
There were many apps which relied on register_globals but
register_globals was introduced.
There were many apps which relied on references in PHP4, but the object
model changed in 5, references too.
There are apps which rely on magic_quotes, but magic
is there any benefit in removing those features? I can see that Code
using these features is probably designed badly or unconventionally, but
php has never been a designers-language...right? It's always been about
being easy to use.
Even without globals you can still use:
Class GLOBALS{
Definitely a -1 for making read only. I kind'a like to apply filters
to POST directly when validating forms so I clean up the user mess in
it and if he makes a mistake in a form, to show him a cleaned up
input. Also this is useful in other ways.
Mixed feelings on other parts. From one point of
Rasmus Lerdorf wrote:
Andrey, you have posted 9 messages on this in the past 3 hours. We have
heard you. You don't need to keep saying the same thing over and over.
And for the record, I strongly disagree with changing this.
As someone who always seems to be doing things the wrong way,
Andrey Hristov wrote:
I am not against global variables, I'm against usage of $GLOBALS and
global.
So how do you support global variables by banning the two ways they can
be accessed?
-1
From a Framework point of view, they should save all of the
(super)global variables from the global
Am 09.12.2010 13:46, schrieb Andrey Hristov:
There were many apps which relied on register_globals but register_globals
was introduced.
There were many apps which relied on references in PHP4, but the object model
changed in 5, references too.
There are apps which rely on magic_quotes, but
Ángel González wrote:
Andrey Hristov wrote:
I am not against global variables, I'm against usage of $GLOBALS and
global.
So how do you support global variables by banning the two ways they can
be accessed?
very easy, by using them by name. Global variables are those outside of
a classes,
Reindl Harald wrote:
Am 09.12.2010 13:46, schrieb Andrey Hristov:
There were many apps which relied on register_globals but register_globals was
introduced.
There were many apps which relied on references in PHP4, but the object model
changed in 5, references too.
There are apps which rely on
Am 09.12.2010 17:19, schrieb Andrey Hristov:
one day you might have to support globalized applications and I am sure
you will feel very enlightened to fix them :)
This is my problem and not yours
There are thousands of scripts that are not big applications
and running well, are secure and
On Thu, Dec 9, 2010 at 5:19 PM, Andrey Hristov p...@hristov.com wrote:
Reindl Harald wrote:
Am 09.12.2010 13:46, schrieb Andrey Hristov:
There were many apps which relied on register_globals but
register_globals was introduced.
There were many apps which relied on references in PHP4, but
Reindl Harald wrote:
Am 09.12.2010 17:19, schrieb Andrey Hristov:
one day you might have to support globalized applications and I am sure
you will feel very enlightened to fix them :)
This is my problem and not yours
sure, one's thrash is another mans cash.
There are thousands of scripts
On Thu, Dec 09, 2010 at 05:40:09PM +0100, Reindl Harald wrote:
Am 09.12.2010 17:19, schrieb Andrey Hristov:
one day you might have to support globalized applications and I am sure
you will feel very enlightened to fix them :)
This is my problem and not yours
There are thousands of
Ferenc Kovacs wrote:
On Thu, Dec 9, 2010 at 5:19 PM, Andrey Hristov p...@hristov.com
mailto:p...@hristov.com wrote:
Reindl Harald wrote:
Am 09.12.2010 13:46, schrieb Andrey Hristov:
There were many apps which relied on register_globals but
Alain Williams wrote:
On Thu, Dec 09, 2010 at 05:40:09PM +0100, Reindl Harald wrote:
Am 09.12.2010 17:19, schrieb Andrey Hristov:
one day you might have to support globalized applications and I am sure
you will feel very enlightened to fix them :)
This is my problem and not yours
There are
Am 09.12.2010 17:49, schrieb Andrey Hristov:
sure, one's thrash is another mans cash.
Stop this dumb style
I know very well which script is good anough with
a simple hack and where i have to do a real
application style and i do not like braindead
ideas forcing me to get lost this decision
On Thu, Dec 9, 2010 at 5:55 PM, Andrey Hristov p...@hristov.com wrote:
If all your functions take 15 params I am worried that your program design
is flawed, sorry.
That's not an argument to do it. PHP and all other languages have many
ways to shoot yourself in the knees, but that's a reason
On Thu, Dec 9, 2010 at 5:58 PM, Pierre Joye pierre@gmail.com wrote:
On Thu, Dec 9, 2010 at 5:55 PM, Andrey Hristov p...@hristov.com wrote:
If all your functions take 15 params I am worried that your program design
is flawed, sorry.
but that's a reason
+not :)
--
Pierre
@pierrejoye
On Thu, 9 Dec 2010, Andrey Hristov wrote:
If all your functions take 15 params I am worried that your program
design is flawed, sorry.
Stop trying to tell people how they should write their code. It's not
any of your business. Pragmatic application design is all great and
wonderfull, but
Reindl Harald wrote:
Am 09.12.2010 17:49, schrieb Andrey Hristov:
sure, one's thrash is another mans cash.
Stop this dumb style
I have been paid quite well for fixing other man's thrash because it
just did not work. Thus, one's thrash is another man's cash. But do we
want this a normal
Andrey Hristov wrote:
Ángel González wrote:
So how do you support global variables by banning the two ways they can
be accessed?
very easy, by using them by name. Global variables are those outside
of a classes, methods and functions.
If they can only be used outside functions they would be
Pierre Joye wrote:
On Thu, Dec 9, 2010 at 5:55 PM, Andrey Hristov p...@hristov.com wrote:
If all your functions take 15 params I am worried that your program design
is flawed, sorry.
That's not an argument to do it. PHP and all other languages have many
ways to shoot yourself in the knees,
On Thu, Dec 9, 2010 at 6:06 PM, Andrey Hristov p...@hristov.com wrote:
Pierre Joye wrote:
On Thu, Dec 9, 2010 at 5:55 PM, Andrey Hristov p...@hristov.com wrote:
If all your functions take 15 params I am worried that your program
design
is flawed, sorry.
That's not an argument to do it.
Ángel González wrote:
Andrey Hristov wrote:
Ãngel González wrote:
So how do you support global variables by banning the two ways they can
be accessed?
very easy, by using them by name. Global variables are those outside
of a classes, methods and functions.
If they can only be used outside
argument...
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: 09 December 2010 16:59
To: Andrey Hristov
Cc: PHP Internals List
Subject: Re: [PHP-DEV] Deprecating global + $GLOBALS, making $_REQUEST,
$_GET, $_POST read-only
On Thu, Dec 9, 2010 at 5:58 PM, Pierre
Andrey Hristov wrote:
You probably got me wrong. The code will be broken and can be fixed.
It's not like going line by line and checking whether everything will
work. I'm tired of explaining this.
SO you are happy to do all that work for us for free?
Only recently has PHP4 been dropped from
Hi Lester,
Lester Caine wrote:
Andrey Hristov wrote:
You probably got me wrong. The code will be broken and can be fixed.
It's not like going line by line and checking whether everything will
work. I'm tired of explaining this.
SO you are happy to do all that work for us for free?
Only
On 9 December 2010 17:08, Pierre Joye pierre@gmail.com wrote:
On Thu, Dec 9, 2010 at 6:06 PM, Andrey Hristov p...@hristov.com wrote:
s,foot,knee, same idea:
http://www.urbandictionary.com/define.php?term=shoot%20yourself%20in%20the%20foot
And it isn't just your foot you can shoot!
On Thu, Dec 9, 2010 at 12:21 PM, Ferenc Kovacs i...@tyrael.hu wrote:
And what about global constants? They are also screwing up the Dependency
Injection, and the static functions/properties, and the singletons also.
Should we ban those?
You got right to the point. It's no use removing this
Hi!
the topic says most of it. What do you think about deprecating the
global keyword and $GLOBALS with it? Together with this making
No, I think it's a bad idea. I know over-using globals is bad, but they
still have their uses and huge amount of apps is using them one way or
another.
On removing globals / $GLOBALS, erm, -1 to that. Just too much legacy code
needs this to work as is.
On making $_POST, $_REQUEST, $_GET et al read only, again -1 for the same
reason. However, I understand the sentiment and it brings up this idea...
What about a new superglobal, $_INPUT, that is
On Thu, 2010-12-09 at 14:58 -0500, Michael Morris wrote:
Since $_INPUT would be read only from inception nothing can break because it
can't be written to. At an INI level the option to turn off the legacy
superglobals it replaces might be added, but that's a separate issue.
The filter
On 12/9/2010 9:53 AM, Andrey Hristov wrote:
.
fixing a design flaw of the past, evolution in other words.
Global and $GLOBALS are not a design flaw! They are a carefully thought
out technique to insure that you do not shoot your self in the foot by
accidentally accessing a global variable
On Thu, Dec 9, 2010 at 11:42, Michael Shadle wrote:
Not to mention, I have had issues (and I can't reproduce it properly
or I would report it) where sometimes i will have a variable in global
scope in one file, and I have to reference it as $GLOBALS['variable']
in another include, or I have
2010/12/9 Ángel González keis...@gmail.com:
Not to mention, I have had issues (and I can't reproduce it properly
or I would report it) where sometimes i will have a variable in global
scope in one file, and I have to reference it as $GLOBALS['variable']
in another include, or I have to global
On Thursday, December 09, 2010 4:44:44 am Michael Shadle wrote:
On Thu, Dec 9, 2010 at 2:38 AM, Andrey Hristov p...@hristov.com wrote:
Yes, as the documentation will mention how to do it, for old
applications. For new apps it is easy - pass all the information you
need as parameter to the
57 matches
Mail list logo
