Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks

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 > with an Iterator class; the first thing might be to check the type of $thi

[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 with this making $_REQUEST, $_GET and $_POST read-only as they should be used only to read-only anyway. The reason for global + GLOBALS is that these are abused and which

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 The same for making $_GET/$_POST/$_REQUEST readonly I know that it is not best practice, but sometimes it makes life easier to

RE: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

+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... In short I like it but I'm not sure how it would ever get implemented

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 and registering of globals was switched off? Th

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 $G

RE: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

-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 mu

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 br

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 2:31 AM, James Butler 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 > become a default setting of

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 2:38 AM, Andrey Hristov 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 PHP? named param

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

2010/12/9 Andrey Hristov > 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 and

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Michael Shadle wrote: On Thu, Dec 9, 2010 at 2:38 AM, Andrey Hristov 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 fo

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Eloy Bote Falcon wrote: 2010/12/9 Andrey Hristov 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 introduc

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 -- http://d

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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.

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 > >

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 than

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

hi, As far as I remember we discussed that already back to the php 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 filter usage instead

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 11:14 AM, Andrey Hristov 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 anyway. > > The

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 12:15 PM, Pierre Joye wrote: > hi, > > As far as I remember we discussed that already back to the php 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 possibl

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Dec 9, 2010, at 3:34, Ferenc Kovacs wrote: > On Thu, Dec 9, 2010 at 12:15 PM, Pierre Joye wrote: > >> hi, >> >> As far as I remember we discussed that already back to the php> mention it> discussions. It was not accepted because of the little >> gains in regard to the major BC breaks. >> >

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Ferenc Kovacs wrote: On Thu, Dec 9, 2010 at 11:14 AM, Andrey Hristov > 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-

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 5:14 AM, Andrey Hristov 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 anyway. I do no

RE: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

-Original Message- From: Ilia Alshanetsky [mailto:i...@prohost.org] On Thu, Dec 9, 2010 at 5:14 AM, Andrey Hristov 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 an

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On 9 December 2010 18:14, 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. -1 here. No question that

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Adam Harvey wrote: On 9 December 2010 18:14, 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. -1 here.

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST 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 m

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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{ pu

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 vie

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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, simp

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 g

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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,

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Á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,

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 c

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 5:19 PM, Andrey Hristov 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 the

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 t

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 thousa

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Ferenc Kovacs wrote: On Thu, Dec 9, 2010 at 5:19 PM, Andrey Hristov > 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 introduc

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 th

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 Ther

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 5:55 PM, Andrey Hristov 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 why we should rem

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 5:58 PM, Pierre Joye wrote: > On Thu, Dec 9, 2010 at 5:55 PM, Andrey Hristov 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 | http://blog.thepimp.net | h

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 t

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 j

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 wo

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Pierre Joye wrote: On Thu, Dec 9, 2010 at 5:55 PM, Andrey Hristov 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 reaso

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 6:06 PM, Andrey Hristov wrote: > Pierre Joye wrote: >> >> On Thu, Dec 9, 2010 at 5:55 PM, Andrey Hristov 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 oth

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Á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 f

RE: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 be

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 sup

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 recent

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On 9 December 2010 17:08, Pierre Joye wrote: > On Thu, Dec 9, 2010 at 6:06 PM, Andrey Hristov 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! http://www.nytimes.com/1999/06/18/nyregi

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thu, Dec 9, 2010 at 12:21 PM, Ferenc Kovacs 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 support if th

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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. $_R

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 r

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 extens

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

On Tue, 07 Dec 2010 07:08:34 -, Gustavo Lopes 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 the ini option changed

[PHP-DEV] PHP Dev RFC Selecting Namespaces and Tag styles at include time.

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 different

Re: [PHP-DEV] PHP Dev RFC Selecting Namespaces and Tag styles at include time.

On Thu, Dec 9, 2010 at 3:53 PM, Michael Morris wrote: > > 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 the > engine to pars

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

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 hav

Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks

On Thu, Dec 9, 2010 at 1:09 AM, Stefan Marr 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 > > with

Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks

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. I

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

2010/12/9 Ángel González : >> 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 $variable

[PHP-DEV] PHP 5.3.4 Released

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 w

[PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.)

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 wrot

[PHP-DEV] PHP 5.2.15 Released!

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

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On Thursday, December 09, 2010 4:44:44 am Michael Shadle wrote: > On Thu, Dec 9, 2010 at 2:38 AM, Andrey Hristov 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. I

Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks

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