Le 02/10/2013 20:41, Jakub Zelenka a écrit :
> Hi,
>
> I was wondering why stream API has been changed in this commit:
>
> https://github.com/php/php-src/commit/92d27ccb0574f901a107409a7fec92888fa2b82f
>
> Basically all char pointers have been constified. The thing is that this
> commit leads to
My understanding is that the const triggers some optimizations because the
compiler better understands how the variables are used.
I'm not sure what degree of a difference it makes, but I'm always a fan of
using const if it's appropriate.
Perhaps your effort is better spent modifying the extensio
On Wed, 2013-10-02 at 19:59 +0200, Michael Wallner wrote:
> On 2 October 2013 16:10, Johannes Schlüter wrote:
> > On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
> >> Since ever people are confused by _GET and _POST superglobals,
> >> because, despite their name, they do not (really) dep
+1! This guy is epic!
On Mon, Sep 30, 2013 at 10:56 PM, Daniel Lowrey wrote:
> Good day, security-conscious internals people.
>
> I'm ready to float an RFC + patch for default SSL/TLS peer verification and
> TLSv1.1/TLSv1.2 support as mentioned in this thread:
>
> http://news.php.net/php.internal
> > Am I the only one thinking this, is there actually someone who is using
> > __construct as re-initialising method?
> >
> php doesn't invoke the parent's constructor from the subclass if the
> subclass also have a constructor, so in that case calling
> parent::__construct() manually is your only
On Wed, Oct 2, 2013 at 7:57 PM, Christopher Jones <
christopher.jo...@oracle.com> wrote:
> I'd like to see float/double casts recognize the locale's decimal
> separator. It's perfectly fine in Oracle DB for numbers to be
> inserted/fetched with "," (or any other character) as the decimal
> separa
> On 02.10.2013, at 10:59, Michael Wallner wrote:
>
>> Since ever people are confused by _GET and _POST superglobals,
>> because, despite their name, they do not (really) depend on the
>> request method. Therefor I propose to phase out $_GET and name it
>> $_QUERY and I propose to phase out $_POS
Hi,
I was wondering why stream API has been changed in this commit:
https://github.com/php/php-src/commit/92d27ccb0574f901a107409a7fec92888fa2b82f
Basically all char pointers have been constified. The thing is that this
commit leads to compilation warning for many extensions.
In my case I use p
On Wed, Oct 2, 2013 at 8:02 PM, Michael Wallner wrote:
> >> There are already parsers for application/x-www-form-urlencoded and
> >> multipart/form-data in the core. One could think of providing an API
> >> to add content type handlers from extensions, ext/json may be an
> >> example, like it is
On 2 October 2013 10:57, Christopher Jones wrote:
> On 10/02/2013 10:26 AM, Nikita Popov wrote:
>> I'd like to change our double-to-string casting behavior to be
>> locale-independent and would appreciate some opinions as to whether you
>> consider this feasible.
>
> I'd like to see float/double c
On 2 October 2013 17:15, Nikita Popov wrote:
> On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner wrote:
>>
>> Since ever people are confused by _GET and _POST superglobals,
>> because, despite their name, they do not (really) depend on the
>> request method. Therefor I propose to phase out $_GET a
On 2 October 2013 16:10, Johannes Schlüter wrote:
> On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
>> Since ever people are confused by _GET and _POST superglobals,
>> because, despite their name, they do not (really) depend on the
>> request method. Therefor I propose to phase out $_G
On 10/02/2013 10:26 AM, Nikita Popov wrote:
Hi internals!
I'd like to change our double-to-string casting behavior to be
locale-independent and would appreciate some opinions as to whether you
consider this feasible.
So, my suggestion is to change the (string) cast to always use "." as the
> Further, I propose to remove the POST method restriction for handling
request bodies and solely rely on the content type to trigger the
parser(s). (*)
+1
This would solve the with parsing multi-form data with PUT requests (and
possibly any future method types), thus enabling full REST support :)
Hi internals!
I'd like to change our double-to-string casting behavior to be
locale-independent and would appreciate some opinions as to whether you
consider this feasible.
So, first off, this is how PHP currently behaves:
https://bugs.php.net/bug.php?id=55160).
3. Another case where thing
On Wed, 2013-10-02 at 17:47 +0200, Florian Anderiasch wrote:
> On 02.10.2013 17:29, Daniel Lowrey wrote:
> > The superglobals are a hopelessly poor abstraction. Can we stop trying to
> > put the proverbial gold ring in the pig's snout on this?
> >
> > [...]
> >
> > Something like the following woul
On 02.10.2013 17:29, Daniel Lowrey wrote:
> The superglobals are a hopelessly poor abstraction. Can we stop trying to
> put the proverbial gold ring in the pig's snout on this?
>
> [...]
>
> Something like the following would be an infinitely superior solution:
>
> interface HttpRequest {
> fu
The superglobals are a hopelessly poor abstraction. Can we stop trying to
put the proverbial gold ring in the pig's snout on this?
While a change to `$_QUERY` and `$_BODY` would undoubtedly be an
improvement I don't think the massive BC breaks that would result are
justified by simply improving va
On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner wrote:
> Since ever people are confused by _GET and _POST superglobals,
> because, despite their name, they do not (really) depend on the
> request method. Therefor I propose to phase out $_GET and name it
> $_QUERY and I propose to phase out $_POS
On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
> Since ever people are confused by _GET and _POST superglobals,
> because, despite their name, they do not (really) depend on the
> request method. Therefor I propose to phase out $_GET and name it
> $_QUERY and I propose to phase out $_PO
UPDATE: I figured out number 2. Maybe I had an extra text node in there,
but now it's working.
Can someone help with the others?
-John
On 9/26/2013 8:12 PM, John Stokes wrote:
Well, fine then.
I'm trying to understand the mechanics behind XMLReader::next() and
XMLReader::read()
Given an X
On Wed, 2013-10-02 at 14:50 +0100, Andrea Faulds wrote:
> > Le 2 octobre 2013 à 13:27, Michael Wallner a écrit :
> >
> >
> > On 2 October 2013 13:12, Leigh wrote:
> > > On 2 October 2013 07:59, Michael Wallner wrote:
> > >
> > > You certainly won't be able to remove $_GET / $_POST (implied by
>
> Le 2 octobre 2013 à 13:27, Michael Wallner a écrit :
>
>
> On 2 October 2013 13:12, Leigh wrote:
> > On 2 October 2013 07:59, Michael Wallner wrote:
> >
> > You certainly won't be able to remove $_GET / $_POST (implied by
> > "phase out") in any 5.x release, it's just too big of a BC break.
>
On 2 October 2013 13:12, Leigh wrote:
> On 2 October 2013 07:59, Michael Wallner wrote:
>
>> I propose to phase out $_GET and name it $_QUERY and
>> I propose to phase out $_POST and name it $_FORM
>
> I have to say I'm against this aspect of the proposal. While the names
> may not be 100% accura
On 2 October 2013 12:00, Andrea Faulds wrote:
>> Le 2 octobre 2013 à 10:58, Michael Wallner a écrit :
>> On 2 October 2013 11:56, Andrea Faulds wrote:
>> > Backwards compatibility matters, so we should keep $_GET and $_POST but add
>> > these as better aliases for them.
>>
>> That's why I said "
On 02.10.2013, at 15:12, Leigh wrote:
> On 2 October 2013 08:31, Michael Wallner wrote:
>>
>> I had it, but I'm not sure $_BODY fits either, because it should be an
>> array. Currently only form data fits the purpose of de-serialisation
>> of a request body.
>>
>
> Not so sure about that. I
On 2 October 2013 07:59, Michael Wallner wrote:
> I propose to phase out $_GET and name it $_QUERY and
> I propose to phase out $_POST and name it $_FORM
I have to say I'm against this aspect of the proposal. While the names
may not be 100% accurate, _most_ people are used to their behaviour.
Yo
> Le 2 octobre 2013 à 10:58, Michael Wallner a écrit :
> On 2 October 2013 11:56, Andrea Faulds wrote:
> > Backwards compatibility matters, so we should keep $_GET and $_POST but add
> > these as better aliases for them.
>
> That's why I said "phase out"... or is it a german anglicism?
It's not.
> Le 2 octobre 2013 à 07:59, Michael Wallner a écrit :
>
> Since ever people are confused by _GET and _POST superglobals,
> because, despite their name, they do not (really) depend on the
> request method. Therefor I propose to phase out $_GET and name it
> $_QUERY and I propose to phase out $_PO
On 2 October 2013 11:39, Lior Kaplan wrote:
> On Sat, Sep 28, 2013 at 3:44 PM, Lior Kaplan wrote:
>
>> On Sat, Sep 28, 2013 at 12:57 PM, Derick Rethans wrote:
>>
>>> And bug 31347 is that was a fix for a specific issue on Windows:
>>> https://bugs.php.net/bug.php?id=31347
>>>
>>
>> The patch ori
On Sat, Sep 28, 2013 at 3:44 PM, Lior Kaplan wrote:
> On Sat, Sep 28, 2013 at 12:57 PM, Derick Rethans wrote:
>
>> And bug 31347 is that was a fix for a specific issue on Windows:
>> https://bugs.php.net/bug.php?id=31347
>>
>
> The patch originates in Debian, and I can assure you that they don't
On 02.10.2013, at 11:24, Michael Wallner wrote:
> On 2 October 2013 09:17, Alexey Zakhlestin wrote:
>
>> 3. expose body-parsers via php-level API
>>
>> +1. Hell, yes! Something like +1000, actually ;)
>
> Uhmmm... I actually meant an interal API not userland :)
well, why not both? :)
stri
On 2 October 2013 09:25, Jannik Zschiesche wrote:
> Hi,
>
> wouldn’t $_BODY be better - since it is the request body?
> $_FORM is imho not very clear, since you can send data to $_POST without
> using a form.
I had it, but I'm not sure $_BODY fits either, because it should be an
array. Currently
Hi,
wouldn’t $_BODY be better - since it is the request body?
$_FORM is imho not very clear, since you can send data to $_POST without using
a form.
--
Cheers
Jannik
Am Mittwoch, 2. Oktober 2013 um 09:17 schrieb Alexey Zakhlestin:
>
> On 02.10.2013, at 10:59, Michael Wallner mailto:m...@
On 2 October 2013 09:17, Alexey Zakhlestin wrote:
> 3. expose body-parsers via php-level API
>
> +1. Hell, yes! Something like +1000, actually ;)
Uhmmm... I actually meant an interal API not userland :)
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscrib
On 02.10.2013, at 10:59, Michael Wallner wrote:
> Since ever people are confused by _GET and _POST superglobals,
> because, despite their name, they do not (really) depend on the
> request method. Therefor I propose to phase out $_GET and name it
> $_QUERY and I propose to phase out $_POST and
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not
100% confident with the latter yet,
37 matches
Mail list logo
