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 that is currently in the wild...
how hard it will be to grep for global and
-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
In short:
Globals can be bad, but not always, it depends on the situation
PHP is about getting stuff done... It gives developers the rope, if they want
to hang themselves thats up to them.
If PHP was designed tomorrow, it might not have globals. but it does, they are
in use and removing them
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 Tue, 07 Dec 2010 07:08:34 -, Gustavo Lopes glo...@nebm.ist.utl.pt
wrote:
The very simple attached patch adds an option to disable POST data
processing, which implies the data can only be read in a stream fashion
through php://input.
I've committed to trunk the patch with the name of
Been pointed this way by some folks that this is the place to set
suggestions on changes to the functions or language. I have two at the
moment, and that is to the including functions (include, require,
include_once, require_once). They need to be considered separately as they
address two
On Thu, Dec 9, 2010 at 3:53 PM, Michael Morris dmgx.mich...@gmail.comwrote:
PHP_TAGS_NONE is suggested as a possible bonus mode this approach allows
that wouldn't be feasible otherwise. In this mode the engine treats the
whole file as PHP and doesn't allow mode switching. This might allow
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
On Thu, Dec 9, 2010 at 1:09 AM, Stefan Marr p...@stefan-marr.de wrote:
Hi Nathan:
On 09 Dec 2010, at 08:44, Nathan Nobbe wrote:
Hi,
I think traits will lend themselves to frequent runtime checking against
the
type of class in which they were used. Consider a trait designed for use
Hi Nathan:
On 09 Dec 2010, at 23:42, Nathan Nobbe wrote:
What I'm getting at is the scenario when a trait is designed to be used in
concert with the class in which it is being used. In this case the trait
expects certain functions to be available on the class in which it is used
with. If
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
The PHP development team is proud to announce the immediate release of
PHP 5.3.4. This is a maintenance release in the 5.3 series, which
includes a large number of bug fixes.
Security Enhancements and Fixes in PHP 5.3.4:
* Fixed crash in zip extract method (possible CWE-170).
* Paths
Forgive me - it's been a *long* time since I've used a listserv, and I'm
still getting the hang of getting the message tags exat. Reposting for those
who may have missed this because I got the exact format of the tags wrong
the first time around.
On Thu, Dec 9, 2010 at 3:53 PM, Michael Morris
The PHP development team would like to announce the immediate
availability of PHP 5.2.15. This release marks the end of support for
PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.
This release focuses on improving the security and stability of the
PHP 5.2.x branch with a small
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
Personally, I believed that traits are a *compile time injection* to a
class, so that at runtime a class behaves completely as it would if trait
methods were implemented directly in the class. That said, everything like
trait requirements for a certain interface, should be done at compile time
and
66 matches
Mail list logo
