RE: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7

> From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of > Julien Pauli, Sent: Tuesday, October 14, 2014 10:05 AM > > On Tue, Oct 14, 2014 at 9:25 AM, Stas Malyshev wrote: >> Hi! >> >>> ... like the hidden array element: http://3v4l.org/6uFqf >>> ... like the hidden object prope

Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7

> On 15 Oct, 2014, at 9:23 am, Stas Malyshev wrote: > > Hi! > >> For the array-to-object conversion, no scanning is necessary, since the >> internal implementation already knows which keys are integers and which >> strings. For the vast majority of cases, the array passed in will have > > C

Re: [PHP-DEV] New globals for PUT and DELETE

Hi! > PHP today to enable successful & easy implementation of RESTful interfaces. Having done this, I beg to differ. > Try to send a parameter in the body, by PUT method, for reading > parameters have to use an ugly way file_get_contents(‘php://input') What exactly is the problem in this one-li

Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7

Hi! > For the array-to-object conversion, no scanning is necessary, since the > internal implementation already knows which keys are integers and which > strings. For the vast majority of cases, the array passed in will have Could you explain this? How you know which keys are integers and whic

Re: [PHP-DEV] RFC: PHP 7.0 timeline

On 10/14/2014 05:20 PM, Tjerk Meesters wrote: > > On 15 Oct 2014, at 01:24, Rasmus Lerdorf wrote: > >> On 10/14/2014 10:14 AM, Stas Malyshev wrote: >>> Hi! >>> IMO, AST, INT64, NG, Uniforme variables style is enough for a new marjor version.. why we still need to wait? >>> >>> We don'

Re: [PHP-DEV] RFC: PHP 7.0 timeline

On 15 Oct 2014, at 01:24, Rasmus Lerdorf wrote: > On 10/14/2014 10:14 AM, Stas Malyshev wrote: >> Hi! >> >>> IMO, AST, INT64, NG, Uniforme variables style is enough for a new >>> marjor version.. why we still need to wait? >> >> We don't need to just "wait", as sit and do nothing. We need to

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014 3:44 PM, "Park Framework" wrote: > > I also implement RESTFul projects, argue need to modify PHP to make it > convenient for RESTFul :) > > The problem is not in the names of global variables, the problem is a > lack of data they, if method request PUT, DELETE. > > But there is not

Re: [PHP-DEV] Unicode support

On 15/10/14 00:04, Rowan Collins wrote: Rowan, Back to combining characters, i dig the idea of introducing graphemes, but i think French person would write word "noël" using precomposed character. I'm using French keyboard at https://translate.google.com/#fr/. "ë" is Shift + "^", then "e", it p

Re: [PHP-DEV] New globals for PUT and DELETE

I also implement RESTFul projects, argue need to modify PHP to make it convenient for RESTFul :) The problem is not in the names of global variables, the problem is a lack of data they, if method request PUT, DELETE. But there is nothing wrong with the renaming and adding aliases, rename $HTTP_GE

RE: [PHP-DEV] New globals for PUT and DELETE

> -Original Message- > From: Park Framework [mailto:park.framew...@gmail.com] > Sent: Wednesday, October 15, 2014 1:16 AM > To: Zeev Suraski > Cc: Kris Craig; Rasmus Lerdorf; Rowan Collins; PHP internals list > Subject: Re: [PHP-DEV] New globals for PUT and DELETE > > 2014-10-15 0:56 GMT+03

Re: [PHP-DEV] New globals for PUT and DELETE

2014-10-15 0:56 GMT+03:00 Zeev Suraski : > PHP today to enable successful & easy implementation of RESTful interfaces. No, now PHP not successful & not easy implementation of RESTful interfaces. Try to send a parameter in the body, by PUT method, for reading parameters have to use an ugly way fi

Re: [PHP-DEV] Unicode support

On 14/10/14 23:48, Johannes Schlüter wrote: On Tue, 2014-10-14 at 23:18 +0300, Aleksey Tulinov wrote: Very good point. I'll give another example: is there a substring "s" in string "Maße"? If it's case-sensitive search, when there is no such substring, but if it's case-insensitive search, then

RE: [PHP-DEV] New globals for PUT and DELETE

> Personally, I like the idea of using more appropriately named aliases, > particularly if they're roughly the same number of characters. However, > we > would need to allow at least several years for people to adopt the new > globals before deprecating $_GET and $_POST. Ultimately, they will eit

Re: [PHP-DEV] New globals for PUT and DELETE

On 14/10/2014 22:43, Rowan Collins wrote: On 14/10/2014 21:21, Rasmus Lerdorf wrote: On 10/14/2014 11:16 AM, Rowan Collins wrote: On 14/10/2014 17:18, Rasmus Lerdorf wrote: I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_G

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 21:47, Stas Malyshev wrote: >> You throw an error. Just as plenty of functions already can’t handle >> ridiculously large integer arguments. > > The problem is, if you function can handle the int range and you checked > for is_int() and everything worked fine - now it's broke

RE: [PHP-DEV] New globals for PUT and DELETE

> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > Sent: Tuesday, October 14, 2014 7:19 PM > To: Mike Dugan; Andrea Faulds; Kristopher > Cc: PHP internals list; Andrey Andreev; Kris Craig > Subject: Re: [PHP-DEV] New globals for PUT and DELETE > > On 10/14/2014 09:15 AM, Mike Dugan wrote: > > I t

Re: [PHP-DEV] New globals for PUT and DELETE

On 14/10/2014 21:21, Rasmus Lerdorf wrote: On 10/14/2014 11:16 AM, Rowan Collins wrote: On 14/10/2014 17:18, Rasmus Lerdorf wrote: I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the

Re: [PHP-DEV] New globals for PUT and DELETE

On Tue, Oct 14, 2014 at 1:21 PM, Rasmus Lerdorf wrote: > On 10/14/2014 11:16 AM, Rowan Collins wrote: > > On 14/10/2014 17:18, Rasmus Lerdorf wrote: > >> I think 20+ years of history has proven this to be a non-issue. Of all > >> the things that people get confused by in PHP, $_GET/$_POST are rig

Re: [PHP-DEV] Unicode support

On 14/10/14 10:04, Aleksey Tulinov wrote: > 1. Is there a need for more Unicode support in PHP? > 2. What is currently missing in that regard? > 3. Is this a good place to ask such questions? I need to ask ... Is this discussion only about improving support for UTF8 content in PHP? What is the cu

Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7

On 14/10/2014 21:58, Stas Malyshev wrote: |$obj = (object)array('123' => '456'); var_dump($obj); Here the array had numeric index, so the object property became numeric index too. The alternative for this would be for this operation to scan through whole array and convert each key from numeric t

Re: [PHP-DEV] Unicode support

On 14/10/2014 20:51, Andrea Faulds wrote: If you went length in characters, you probably need to implement your own algorithm, as it really depends on your specific use case. I disagree, Unicode has very well-defined algorithms for these things, and the average PHP developer (or even PHP fram

Re: [PHP-DEV] Unicode support

On 14/10/2014 21:18, Aleksey Tulinov wrote: Back to combining characters, i dig the idea of introducing graphemes, but i think French person would write word "noël" using precomposed character. I'm using French keyboard at https://translate.google.com/#fr/. "ë" is Shift + "^", then "e", it pro

Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7

Hi! > Please correct me if I'm wrong but object properties should be strings > in all cases. In all cases where they are assigned as object properties. If they were produced by other means, it can be different. > So all properties set should be converted to string means the following > should be

Re: [PHP-DEV] Unicode support

On Tue, 2014-10-14 at 23:18 +0300, Aleksey Tulinov wrote: > Very good point. I'll give another example: is there a substring "s" in > string "Maße"? If it's case-sensitive search, when there is no such > substring, but if it's case-insensitive search, then "ß" folds into "ss" > and substring "s"

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > You throw an error. Just as plenty of functions already can’t handle > ridiculously large integer arguments. The problem is, if you function can handle the int range and you checked for is_int() and everything worked fine - now it's broken because is_int() no longer implies fixed range and

Re: [PHP-DEV] New globals for PUT and DELETE

On 10/14/2014 11:16 AM, Rowan Collins wrote: > On 14/10/2014 17:18, Rasmus Lerdorf wrote: >> I think 20+ years of history has proven this to be a non-issue. Of all >> the things that people get confused by in PHP, $_GET/$_POST are right >> near the bottom of the list. > > The popularity of REST is

Re: [PHP-DEV] Unicode support

On 14/10/14 21:01, Rowan Collins wrote: Rowan, As I've mentioned before, a lot of the time what people actually want to deal with is "grapheme clusters" - the kind of thing that you'd think of as a character if you were writing by hand. Most people, if asked the length of the string "noël", wo

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 20:46, Rowan Collins wrote: > Just to break this down a bit: > > 1) The RFC should probably aim to make array keys consistent across > platforms. This is currently left as an unanswered question in the RFC, but > it seems natural to include it if the stated aim is to elimin

Re: [PHP-DEV] Unicode support

On 14 Oct 2014, at 19:01, Rowan Collins wrote: > >> If you want to see a pragmatic, actually working, work-in-progress attempt >> at better PHP unicode support, see this: https://github.com/krakjoe/ustring > > It looks like a good prototype, but glancing at the documentation, I'm not > clear

Re: [PHP-DEV] New globals for PUT and DELETE

Hi, On Tue, Oct 14, 2014 at 6:56 PM, Rasmus Lerdorf wrote: > On 10/14/2014 06:29 AM, Andrea Faulds wrote: >> >> On 14 Oct 2014, at 14:27, Kristopher wrote: >> >>> $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. >> >> Ew, non-superglobals. >> >> But $_REQUEST_BODY and $_QUERY_ST

Re: [PHP-DEV] [RFC] Big Integer Support

On 14/10/2014 19:53, Lester Caine wrote: On 14/10/14 19:33, Andrea Faulds wrote: On 14 Oct 2014, at 19:29, Lester Caine wrote: If a 64bit build of PHP is using a simple integer key for a BIGINT key from the database, what will be the equivalent on a 32bit build? It may be that we have to add

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 19:53, Lester Caine wrote: > The real life situation is that databases have used a 64bit integer as > the primary key for records in a table for a long time now. Loading > these records into arrays using the primary key as the array key is a > natural process but as you have i

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 19:39, Stas Malyshev wrote: >> We already have this danger for another type: boolean. phpng got rid >> of IS_BOOL in favour of IS_TRUE and IS_FALSE. If we can update >> everything to handle the IS_BOOL change, surely we can update >> everything to handle bigints, too. > > No,

Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7

On 14.10.2014 09:25, Stas Malyshev wrote: > Hi! > >> ... like the hidden array element: http://3v4l.org/6uFqf >> ... like the hidden object property: http://3v4l.org/RPJXH > The issue seems to be that array lookup always looks for numeric results > when looking for numeric-like keys. But when addi

Re: [PHP-DEV] [RFC] Big Integer Support

On 14/10/14 19:33, Andrea Faulds wrote: > > On 14 Oct 2014, at 19:29, Lester Caine wrote: > >> If a 64bit build of PHP is using a simple integer key for a BIGINT key >> from the database, what will be the equivalent on a 32bit build? >> >> It may be that we have to add code to the DB drivers to

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > We already have this danger for another type: boolean. phpng got rid > of IS_BOOL in favour of IS_TRUE and IS_FALSE. If we can update > everything to handle the IS_BOOL change, surely we can update > everything to handle bigints, too. No, it's not the same thing at all. For bool, you still

Re: [PHP-DEV] New globals for PUT and DELETE

I'm sure the previous 50+ messages are bikeshedding on names for new superglobals, so going to skip them (sorry for anyone who had a valid point). So, my 2p, the entity bodies of PUT and DELETE should go in $_POST (yes, keeping that name) - I see no reason to cater for other methods outside of the

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 19:29, Lester Caine wrote: > If a 64bit build of PHP is using a simple integer key for a BIGINT key > from the database, what will be the equivalent on a 32bit build? > > It may be that we have to add code to the DB drivers to ensure that > BIGINT remains a standard string co

Re: [PHP-DEV] RFC: PHP 7.0 timeline

I like the 1 year timeline. It is an aggressive but achievable goal. On Tue, Oct 14, 2014 at 3:08 AM, Zeev Suraski wrote: > All, > > > > We’ve had some discussions about it during the version name & phpng RFC > processes, and now that 5.6.0 is behind us – I think it’s time to get a > more concre

Re: [PHP-DEV] [RFC] Big Integer Support

On 14/10/14 19:03, Andrea Faulds wrote: >>> I don't see why you'd have two code paths. If you need bigints and they >>> >> are not there, then you just fail, like with any extension your code >>> >> needs and is not installed. If it's there, you just continue working. >>> >> All the code existing n

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 19:11, Stas Malyshev wrote: > Hi! > >> Still, it’s inconvenient. More for developers to worry about. > > I still have no idea why one would need a bigint constant, could you > give an common example where you would do that? The main point is why you should prohibit it. The

Re: [PHP-DEV] New globals for PUT and DELETE

On 14/10/2014 17:18, Rasmus Lerdorf wrote: I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. The popularity of REST is what has changed this. Until people started writing RES

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > Still, it’s inconvenient. More for developers to worry about. I still have no idea why one would need a bigint constant, could you give an common example where you would do that? > No, only extensions. It is *completely* transparent to userland. > That’s the whole point. I'm not sure how

Re: [PHP-DEV] New globals for PUT and DELETE

On 14/10/2014 14:57, Kris Craig wrote: It's not supposed to functionally differ. It's supposed to create some better consistency and make it easier for devs to differentiate between different REST methods when retrieving data. If REQUEST_METHOD is PUT, then I can set the parsed params to the va

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 18:48, Lester Caine wrote: > On 14/10/14 18:25, Stas Malyshev wrote: >> I don't see why you'd have two code paths. If you need bigints and they >> are not there, then you just fail, like with any extension your code >> needs and is not installed. If it's there, you just contin

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 18:25, Stas Malyshev wrote: > Hi! > >> I'm not sure what this would solve. Sure, you could just use objects >> instead of a new type, but both present exactly the same challenges. >> Adding a new type isn't hard in itself. The problem is updating >> everything which handles n

Re: [PHP-DEV] Unicode support

On 14/10/2014 14:50, Andrea Faulds wrote: 2. What is currently missing in that regard? Unicode string support. I know that was probably deliberately flippant, but I think there is a genuine question to be asked here. A lot of people talk about "Unicode support" like they talk about "XPath su

Re: [PHP-DEV] [RFC] Big Integer Support

On 14/10/14 18:25, Stas Malyshev wrote: > I don't see why you'd have two code paths. If you need bigints and they > are not there, then you just fail, like with any extension your code > needs and is not installed. If it's there, you just continue working. > All the code existing now doesn't need b

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > I'm not sure what this would solve. Sure, you could just use objects > instead of a new type, but both present exactly the same challenges. > Adding a new type isn't hard in itself. The problem is updating > everything which handles numbers and their associated tests. This Exactly. Since ob

Re: [PHP-DEV] RFC: PHP 7.0 timeline

On 10/14/2014 10:14 AM, Stas Malyshev wrote: > Hi! > >> IMO, AST, INT64, NG, Uniforme variables style is enough for a new >> marjor version.. why we still need to wait? > > We don't need to just "wait", as sit and do nothing. We need to allocate > time for other features. There are also quite a

Re: [PHP-DEV] RFC: PHP 7.0 timeline

Hi! > IMO, AST, INT64, NG, Uniforme variables style is enough for a new > marjor version.. why we still need to wait? We don't need to just "wait", as sit and do nothing. We need to allocate time for other features. > New features which missed PHP7.0, they can target at 7.1 instead. Only featu

Re: [PHP-DEV] New globals for PUT and DELETE

On 14/10/14 17:02, Johannes Schlüter wrote: > On Tue, 2014-10-14 at 14:53 +0100, Chris Wright wrote: > >> PECL HTTP v2 already has this, actually: >> http://devel-m6w6.rhcloud.com/mdref/http/Env/Request# >> >> Also, I think Mike got the naming right there as well, $form is the >> accurate descrip

Re: [PHP-DEV] New globals for PUT and DELETE

On 14/10/14 16:08, Mike Dugan wrote: > Did I just name a global variable? W00t! I guess Chris meant pecl_http's http\Env\Request::$form property. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New globals for PUT and DELETE

On 14/10/14 15:20, Ben Ramsey wrote: > I suppose we could make a super global that returns that for us, but it’s > just as easy to > use the above. Additionally, you might not want to put the full body of the > request into > memory like that. You might rather read the stream only a few bytes at

Re: [PHP-DEV] Unicode support

On 14/10/14 16:50, Andrea Faulds wrote: If you want to see a pragmatic, actually working, work-in-progress attempt at better PHP unicode support, see this: https://github.com/krakjoe/ustring It would add a UString class to PHP for Unicode strings. This would make Unicode text manipulation muc

Re: [PHP-DEV] New globals for PUT and DELETE

Erratum: all the request_* functions except request_get() take the request object/array as 1st argument. Le 14 oct. 2014 18:21, "Florian Margaine" a écrit : > > Hi, > > If it were me, I'd rather delete all the superglobals. It's a horrible API, I don't think anyone can deny that. Now of course, i

Re: [PHP-DEV] New globals for PUT and DELETE

Hi, If it were me, I'd rather delete all the superglobals. It's a horrible API, I don't think anyone can deny that. Now of course, it'd break a tons of code, so I don't suggest to actually delete it. However, instead of trying to work around current superglobals and trying to provide meaningful n

Re: [PHP-DEV] New globals for PUT and DELETE

On 10/14/2014 09:15 AM, Mike Dugan wrote: > On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com > ) wrote: >> On 10/14/2014 06:29 AM, Andrea Faulds wrote: >> > >> > On 14 Oct 2014, at 14:27, Kristopher wrote: >> > >> >> $_HTTP_REQUEST_BODY and $_HT

Re: [PHP-DEV] New globals for PUT and DELETE

On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com) wrote: On 10/14/2014 06:29 AM, Andrea Faulds wrote: > > On 14 Oct 2014, at 14:27, Kristopher wrote: > >> $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. > > Ew, non-superglobals. > > But $_REQ

Re: [PHP-DEV] New globals for PUT and DELETE

On 10/14/2014 06:29 AM, Andrea Faulds wrote: > > On 14 Oct 2014, at 14:27, Kristopher wrote: > >> $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. > > Ew, non-superglobals. > > But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for > $_GET) and $_BODY (

Re: [PHP-DEV] New globals for PUT and DELETE

2014-10-14 18:31 GMT+03:00 Mike Dugan : > The entire point of this debate is that $_GET are passed through the URL and > not necessarily indicative of a GET (HTTP) action. You could just as easily > POST data to a URL with parameters, so although you would access those URL > params via $_GET, th

Re: [PHP-DEV] New globals for PUT and DELETE

Alain Williams wrote (on 14/10/2014): On Tue, Oct 14, 2014 at 01:54:55PM +0100, Andrea Faulds wrote: On 14 Oct 2014, at 13:47, Kris Craig wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currentl

Re: [PHP-DEV] New globals for PUT and DELETE

On October 14, 2014 at 11:23:13 AM, Lester Caine (les...@lsces.co.uk) wrote: On 14/10/14 14:41, Mike Dugan wrote:  > * $_REQUEST - query string and request body parameters  >  > Makes more sense than $_GET and $_POST.  That was actually Andrea’s reply. I don’t the intent was the $_REQUEST is new,

Re: [PHP-DEV] Unicode support

On 14 October 2014 16:09, Aleksey Tulinov wrote: > On 14/10/14 14:00, Chris Wright wrote: > > Chris, > >>> Latter is referring to difficulties like "excess memory usage" and >>> "rewrite >>> the language". I'm developing an open-source Unicode implementation >>> library >>> (nunicode), and it does

Re: [PHP-DEV] New globals for PUT and DELETE

On 14/10/14 14:41, Mike Dugan wrote: > * $_REQUEST - query string and request body parameters > > Makes more sense than $_GET and $_POST. Am I missing something. I've used $_REQUEST since day one since the form returns are always a combination of the Post and url data ... All right if state va

Re: [PHP-DEV] Unicode support

On 14/10/14 14:00, Chris Wright wrote: Chris, Latter is referring to difficulties like "excess memory usage" and "rewrite the language". I'm developing an open-source Unicode implementation library (nunicode), and it doesn't consume any heap at all, it also works on native binary strings, as PH

Re: [PHP-DEV] New globals for PUT and DELETE

On Tue, 2014-10-14 at 14:53 +0100, Chris Wright wrote: > > Agreed, and it seems that’s what PHP-FIG is working on for user land: > > https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md It is great that such things are standardized in userland form - I'm strongly in favor

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 October 2014 15:25, Andrea Faulds wrote: > > On 14 Oct 2014, at 15:20, Park Framework wrote: > >> 2014-10-14 17:09 GMT+03:00 Mike Dugan : >>> If no one else is already working on it, I can write one up this >>> morning/early this afternoon and submit it. >> >> Ok >> The RFC In this topic wi

Re: [PHP-DEV] New globals for PUT and DELETE

On Tue, 2014-10-14 at 14:29 +0100, Andrea Faulds wrote: > * $_BODY- request body parameters I think this name is confusing and unclear. I don't have an alternative, though. (Only suggestion: stick with the established name which can be taught easily ("See method attribute in HTML tag"), sligh

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 October 2014 15:25, Mike Dugan wrote: > On October 14, 2014 at 10:21:34 AM, Ben Ramsey (b...@benramsey.com) wrote: > > > On Oct 14, 2014, at 9:08 AM, Mike Dugan wrote: > >> On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: >>> >>> >>> So $_QUERY and $_FORM, then. That s

Re: [PHP-DEV] New globals for PUT and DELETE

> On 14 Oct 2014, at 15:25, Mike Dugan wrote: > > That’s my understanding. There’s also some discussion about deriving data > from $_POST/$_FORM that is intended for use with other HTTP verbs, I’m still > trying to ascertain exactly what was in mind there (Andrea I think you > suggested that

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 Oct 2014, at 15:20, Park Framework wrote: > 2014-10-14 17:09 GMT+03:00 Mike Dugan : >> If no one else is already working on it, I can write one up this >> morning/early this afternoon and submit it. > > Ok > The RFC In this topic will be included support Rquest - Content-Type: > applicat

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 Oct 2014, at 15:21, Ben Ramsey wrote: > +1 > > I’m cool with $_QUERY and $_FORM. They make much more sense and don’t try to > use HTTP verbs, which can confuse the content and semantics of the data they > contain. Plus, they would just alias $_GET and $_POST, respectively, right? That’

Re: [PHP-DEV] New globals for PUT and DELETE

On October 14, 2014 at 10:21:34 AM, Ben Ramsey (b...@benramsey.com) wrote: On Oct 14, 2014, at 9:08 AM, Mike Dugan wrote: > On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: >> >> >> So $_QUERY and $_FORM, then. That sounds about right. >> > > Did I just name a

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 9:20 AM, Park Framework wrote: > 2014-10-14 17:09 GMT+03:00 Mike Dugan : >> If no one else is already working on it, I can write one up this >> morning/early this afternoon and submit it. > > Ok > The RFC In this topic will be included support Rquest - Content-Type: > appli

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 9:08 AM, Mike Dugan wrote: > On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: >> >> >> So $_QUERY and $_FORM, then. That sounds about right. >> > > Did I just name a global variable? W00t! > > Anyhow, yeah neither one is technically 100% correct, b

Re: [PHP-DEV] New globals for PUT and DELETE

2014-10-14 17:09 GMT+03:00 Mike Dugan : > If no one else is already working on it, I can write one up this > morning/early this afternoon and submit it. Ok The RFC In this topic will be included support Rquest - Content-Type: application/json? It is mandatory for RESTFull. -- PHP Internals - PH

Re: [PHP-DEV] New globals for PUT and DELETE

--  Mike Dugan m...@mjdugan.com On October 14, 2014 at 10:08:56 AM, Chris Wright (c...@daverandom.com) wrote: On 14 October 2014 14:57, Kris Craig wrote:  > On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright wrote:  >  >>  >> ...but is also the wrong solution. It's not scalable,  >  >  > How is it

Re: [PHP-DEV] New globals for PUT and DELETE

On October 14, 2014 at 10:07:26 AM, Park Framework (park.framew...@gmail.com) wrote: 2014-10-14 16:29 GMT+03:00 Andrea Faulds :  >  > On 14 Oct 2014, at 14:27, Kristopher wrote:  >  >> $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.  >  > Ew, non-superglobals.  >  > But $_REQUES

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 October 2014 14:57, Kris Craig wrote: > On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright wrote: > >> On 14 October 2014 14:46, Kris Craig wrote: >> > On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan wrote: >> > >> >> >> >> On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: >> >

Re: [PHP-DEV] New globals for PUT and DELETE

On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: On 14 Oct 2014, at 14:53, Chris Wright wrote: > Also, I think Mike got the naming right there as well, $form is the > accurate description of what it is. You’re right, actually. multipart and url-encoded are usually pr

Re: [PHP-DEV] New globals for PUT and DELETE

2014-10-14 16:29 GMT+03:00 Andrea Faulds : > > On 14 Oct 2014, at 14:27, Kristopher wrote: > >> $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. > > Ew, non-superglobals. > > But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for > $_GET) and $_BODY (for $

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 Oct 2014, at 14:53, Chris Wright wrote: > Also, I think Mike got the naming right there as well, $form is the > accurate description of what it is. You’re right, actually. multipart and url-encoded are usually produced by forms, and other types of request bodies (JSON, plaintext) don’t e

Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7

On Mon, 2014-10-13 at 23:06 -0700, Stas Malyshev wrote: > - drop incompatible $this context calls (probably seriously messed up > code) Before removing: Could anybody check whether this breaks PEAR (incl. `pecl install`) I don't know how much PHP 4 legacy which required such tricks is still in the

Re: [PHP-DEV] New globals for PUT and DELETE

On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright wrote: > On 14 October 2014 14:46, Kris Craig wrote: > > On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan wrote: > > > >> > >> On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: > >> > >> > >> On 14 Oct 2014, at 14:27, Kristopher > wr

Re: [PHP-DEV] New globals for PUT and DELETE

On Tue, Oct 14, 2014 at 01:54:55PM +0100, Andrea Faulds wrote: > > On 14 Oct 2014, at 13:47, Kris Craig wrote: > > > Hey guys, > > > > Does anybody know why we have $_GET and $_POST, but not $_PUT and > > $_DELETE? As far as I can tell, the only way to get these out currently is > > to parse t

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:42 AM, Kris Craig wrote: > Removing or renaming $_GET and $_POST would also create confusion and > almost certainly cause widespread BC breakage on a pretty massive scale. > And there's really no gain to offset that. So that just leaves us with > either continuing to have

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 October 2014 14:33, Ben Ramsey wrote: > > On Oct 14, 2014, at 8:30 AM, Chris Wright wrote: >> I suggested this a while ago, people didn't like the idea, and I'm not >> sure I do any more, either. We'd do much better focusing on creating a >> standard native request *object* which provides c

Re: [PHP-DEV] New globals for PUT and DELETE

On Tue, Oct 14, 2014 at 6:47 AM, Andrea Faulds wrote: > > On 14 Oct 2014, at 14:42, Kris Craig wrote: > > > I don't think that would be a good idea, either. They require more > typing > > and it'd probably be a lot easier for devs to remember which one means > GET > > and which one means POST.

Re: [PHP-DEV] Unicode support

On 14 Oct 2014, at 10:04, Aleksey Tulinov wrote: > I would appreciate if someone would point me to a good read or explain > collective opinion on this topic. I'm basically interested in the following > questions: > > 1. Is there a need for more Unicode support in PHP? Yes. > 2. What is curr

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 October 2014 14:46, Kris Craig wrote: > On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan wrote: > >> >> On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: >> >> >> On 14 Oct 2014, at 14:27, Kristopher wrote: >> >> > $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 Oct 2014, at 14:42, Kris Craig wrote: > I don't think that would be a good idea, either. They require more typing > and it'd probably be a lot easier for devs to remember which one means GET > and which one means POST. I’ve already proposed the shorter $_QUERY and $_BODY. > PHP is suppo

Re: [PHP-DEV] New globals for PUT and DELETE

--  Mike Dugan m...@mjdugan.com On October 14, 2014 at 9:42:47 AM, Kris Craig (kris.cr...@gmail.com) wrote: On Tue, Oct 14, 2014 at 6:25 AM, Andrea Faulds wrote:  >  > On 14 Oct 2014, at 14:23, Andrey Andreev wrote:  >  > > That being said, from a purely semantic prospective, both $_GET and 

Re: [PHP-DEV] New globals for PUT and DELETE

On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan wrote: > > On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: > > > On 14 Oct 2014, at 14:27, Kristopher wrote: > > > $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. > > Ew, non-superglobals. > > But $_REQUEST_BODY

Re: [PHP-DEV] New globals for PUT and DELETE

On Tue, Oct 14, 2014 at 6:25 AM, Andrea Faulds wrote: > > On 14 Oct 2014, at 14:23, Andrey Andreev wrote: > > > That being said, from a purely semantic prospective, both $_GET and > > $_POST should be tossed - yes. In reality, you can't do that because > > virtually all PHP applications use them

Re: [PHP-DEV] New globals for PUT and DELETE

On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: On 14 Oct 2014, at 14:27, Kristopher wrote:  > $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.  Ew, non-superglobals.  But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET)

[PHP-DEV] Fixes for Visual Studio 2014

Hello all. Partially fueled by a joke to get PHP to compile on Windows 10, and partially fueled by starting to look more into core, I found some issues with the javascript-based configuration under Windows 10 and Visual Studio 2014 as well as issues where VS2014 includes better C support than olde

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:30 AM, Chris Wright wrote: > I suggested this a while ago, people didn't like the idea, and I'm not > sure I do any more, either. We'd do much better focusing on creating a > standard native request *object* which provides clean access to this > data, and other things that a

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 October 2014 14:25, Andrea Faulds wrote: > > On 14 Oct 2014, at 14:23, Andrey Andreev wrote: > >> That being said, from a purely semantic prospective, both $_GET and >> $_POST should be tossed - yes. In reality, you can't do that because >> virtually all PHP applications use them. But this

Re: [PHP-DEV] New globals for PUT and DELETE

On 14 Oct 2014, at 14:27, Kristopher wrote: > $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but i

  1   2   >