Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

[Sherif Ramadan]

>
>
>  I have no strong opinion
> either way, but anyway it cannot work as is, because var_export
> already has a second optional parameter (bool $return = false).
>


Yes, I meant the third argument. I updated the RFC to reflect that. Sorry.



> Moreover the RFC currently says that var_export([1, 2, 3]) produces
> ```
> array(1, 2, 3)
> ```
> but it actually produces
> ```
> array (
>   0 => 1,
>   1 => 2,
>   2 => 3,
> )
> ```
>
>

Also true, I fixed this in the RFC as well and sorry for the confusion.



> Regards,
>
> --
> Guilliam Xavier
>

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

[Sherif Ramadan]

On Wed, Apr 8, 2020 at 9:37 AM Derick Rethans  wrote:

>
>
It's different. Changing from long to short array syntax makes it
> unparsable by older versions of PHP.
>

All versions of PHP which don't support short array syntax have long been
EOL for nearly 5 years now. We can't possibly be expected to account for
unsupported versions of PHP here.

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

[Sherif Ramadan]

On Wed, Apr 8, 2020 at 9:22 AM Benjamin Morel 
wrote:

> > VAR_EXPORT_NO_INDEX
>
> Note that I wouldn't consider a BC break to change var_export()'s
> behaviour to always discard indexes when they're numeric, I'm not sure this
> should even be an option!
>
>
Well, it might if people are testing the output of var_export(), like in
the phpt tests. I wouldn't have considered the short array syntax a BC
break either if it weren't for that little pot hole.



> - Ben
>

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

[Sherif Ramadan]

So to recap on what's been discussed so far, because I plan to bring this
to a vote next week...

I am updating the RFC to reflect that the change will no longer break
backwards compatibility. I will be adding an flags argument with the
following 3 optional bitwise flags for var_export:

- VAR_EXPORT_SHORT_ARRAY [Triggers short-array syntax]
- VAR_EXPORT_NO_INDEX [Discards numbered indexes in arrays (only if they
are sequential from 0)]
- VAR_EXPORT_NO_WHITESPACE [For one-liners]

This complicates the implementation slightly, but I think it brings a
greater net-benefit.

On Fri, Apr 3, 2020 at 5:19 PM Sherif Ramadan 
wrote:

>
>
> On Fri, Apr 3, 2020 at 5:16 PM Andrea Faulds  wrote:
>
>> Hey Sara,
>>
>> Sara Golemon wrote:
>> > On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler 
>> wrote:
>> >
>> >> Just out of curiosity, is there any reason we couldn't add an optional
>> >> parameter called "$short_array" or whatever that defaults to false?
>> Then
>> >> there shouldn't be any backwards compatibility issues.
>> >>
>> >> None at all, though I'd make it an `int $options = 0` similar to
>> > json_encode().  I'd have a FAR easier time supporting that than a
>> wholesale
>> > BC break for the sake of breaking BC.
>> >
>> > I can think of a few options:
>> >VAR_EXPORT_SHORT_ARRAY => use [] instead of arrray()
>> >VAR_EXPORT_NO_WHITESPACE => Keep it concise, single line
>> >VAR_EXPORT_NO_VECTOR_INDEX => If an array is vector-like, skip
>> indexes
>> >VAR_EXPORT_UTF8_UESCAPE => Detect places where we can use \u{1234}
>> syntax
>> > for UTF8 strings
>> >
>> > Though I'm going to stay with my stated position that I would MUCH
>> rather
>> > this stuff live in userspace.  Just because PHP's penchant for
>> > including the kitchen sink is broken already doesn't mean we should
>> break
>> > it more.
>>
>>
> +1 for me
>
>
>> As you say, including the kitchen sink might be excessive, but I think
>> adding a $flags option isn't a bad idea — it's low-maintenance, simple
>> to implement and, in my opinion, would be frequently used. We can have
>> the best of both worlds: consistent default behaviour, and nicer output
>> for those who want it. I can see myself using VAR_EXPORT_SHORT_ARRAY and
>> VAR_EXPORT_NO_VECTOR_INDEX (not with that name…) :)
>>
>
> *Fingers crossed*
>
>
>> (Also, if we make the output of var_export() more palatable, will people
>> use it instead of print_r() for development purposes? I can dream…)
>>
>> Thanks,
>> Andrea
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

[Sherif Ramadan]

On Fri, Apr 3, 2020 at 5:16 PM Andrea Faulds  wrote:

> Hey Sara,
>
> Sara Golemon wrote:
> > On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler 
> wrote:
> >
> >> Just out of curiosity, is there any reason we couldn't add an optional
> >> parameter called "$short_array" or whatever that defaults to false? Then
> >> there shouldn't be any backwards compatibility issues.
> >>
> >> None at all, though I'd make it an `int $options = 0` similar to
> > json_encode().  I'd have a FAR easier time supporting that than a
> wholesale
> > BC break for the sake of breaking BC.
> >
> > I can think of a few options:
> >VAR_EXPORT_SHORT_ARRAY => use [] instead of arrray()
> >VAR_EXPORT_NO_WHITESPACE => Keep it concise, single line
> >VAR_EXPORT_NO_VECTOR_INDEX => If an array is vector-like, skip indexes
> >VAR_EXPORT_UTF8_UESCAPE => Detect places where we can use \u{1234}
> syntax
> > for UTF8 strings
> >
> > Though I'm going to stay with my stated position that I would MUCH rather
> > this stuff live in userspace.  Just because PHP's penchant for
> > including the kitchen sink is broken already doesn't mean we should break
> > it more.
>
>
+1 for me


> As you say, including the kitchen sink might be excessive, but I think
> adding a $flags option isn't a bad idea — it's low-maintenance, simple
> to implement and, in my opinion, would be frequently used. We can have
> the best of both worlds: consistent default behaviour, and nicer output
> for those who want it. I can see myself using VAR_EXPORT_SHORT_ARRAY and
> VAR_EXPORT_NO_VECTOR_INDEX (not with that name…) :)
>

*Fingers crossed*


> (Also, if we make the output of var_export() more palatable, will people
> use it instead of print_r() for development purposes? I can dream…)
>
> Thanks,
> Andrea
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sherif Ramadan]

On Mon, Mar 30, 2020 at 1:19 PM Sara Golemon  wrote:

> On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan 
> wrote:
>
>> @Sara Golemon 
>>
>>
>>> Ditto Danack's question, adding: "Then why not use brick/varexporter?"
>>>
>>> -Sara
>>>
>>
>> I punt the question back to you and ask why not use PHP?
>>
>> Simple. Because an implementation in script code is more agile, more
> accessible, and more maintainable in the long term. It's better in every
> way except default availability.  Considering the *1 line* required to make
> it available in a project, this is not a compelling reason.  Conversely,
> avoiding unnecessary breakage of existing code over a matter of aesthetics
> IS a compelling reason.
>
> Now, will you answer my question?
>

Simple. Because an implement in php-src is more available, does not appear
to have a lot of maintenance overhead, is easy to implement and it's better
in every way. Considering the 6 lines of code required to make this change
available to everyone. Given that code is meant for human consumption and
given that aesthetics play a big role in code readability I would say that
conversely doing it IS a compelling reason.

Apart from the 25 phpt tests that (in my opinion) are testing the wrong
thing in the first place, what major projects do you know of that would
break as a result of this change? And I'm not talking about more tests that
test the output of var_export() because that's a breakage I can live with.
If you were using the function as intended you would only be testing that
it gives you back valid PHP code and not trying to test its literal output.


> -Sara
>

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sherif Ramadan]

>
>
> Aesthetics are irrelevant for a computer.
>
> This change does not improve anything and only breaks compatibility. Bad
> idea.
>
>
I beg to differ. While code may be meant for execution by a machine it is
actually intended for human consumption. Aesthetics matter to a human
reading the code.

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sherif Ramadan]

@Sara Golemon 


> Ditto Danack's question, adding: "Then why not use brick/varexporter?"
>
> -Sara
>

I punt the question back to you and ask why not use PHP?

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sherif Ramadan]

@Dan Ackroyd 

> That's an aesthetic choice, which not everyone will agree with.
>

Yes, I freely state that in the RFC. Everyone is free to vote how they like.



>
> "There shouldn't be any backwards incompatible changes"
>
> It apparently breaks 25 tests that compare the output of var_export
> with an expected version. Userland users who have similar tests will
> experience similar breaks.
>
>
A test that compares var_export output is a pretty broken test, in my
opinion. This is similar to a test that would use the value of a constant
to test that the constant works. You're testing PHP code you shouldn't care
if it uses the long form array construct or short form. Just test that it
gives you an array.

With that said, I will update the RFC to make note of these tests and I
will fix them should the RFC be voted in.


> Is there any reason to do this change other than aesthetic choice?
>
>
Just because it is aesthetic is not actually an argument against. Why
wouldn't you want to improve the aesthetics of PHP? Is it only an aesthetic
choice, however? Not entirely. I also state that it is easier to read and
type (saves space) and is more inline with JSON notation which is a lot
more ubiquitous these days. These are all pros. I see no cons in that
change.

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Change var_export() array syntax to use shorthand arrays

[Sherif Ramadan]

Hey Andrea,

Thanks for that. Good catch on the stdClass and __set_state parts. I
neglected those in RFC, but I will add them. But they are still all
forwards compatible changes so no major impact.

On Sun, Mar 29, 2020 at 6:42 PM Andrea Faulds  wrote:

> Hi again,
>
> Andrea Faulds wrote:
> > Hi Sherif,
> >
> > Sherif Ramadan wrote:
> >> I'm proposing a new RFC to change var_export()'s array syntax to use the
> >> short hand array syntax instead.
> >>
> >> The RFC is available here
> >> https://wiki.php.net/rfc/var-export-array-syntax
> >>
> >> This is a forwards-compatible change proposed for and targeting PHP 8.0.
> >>
> >> I'd like to open up discussion.
> >>
> >
> > What about stdClass? That is currently exported using an object cast
> > applied to an array literal, and that array literal uses long array
> > syntax for consistency. I think this should be mentioned in the RFC,
> > whatever choice you make.
>
> Oops, I forgot about classes with ::__set_state! (I only thought about
> stdClass because it was me that added support for it, unlike for
> __set_state.) That also uses the old array syntax.
>
> Thanks and sorry for spam,
> Andrea
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sherif Ramadan]

I'm proposing a new RFC to change var_export()'s array syntax to use the
short hand array syntax instead.

The RFC is available here https://wiki.php.net/rfc/var-export-array-syntax

This is a forwards-compatible change proposed for and targeting PHP 8.0.

I'd like to open up discussion.

Re: [PHP-DEV] Associated Arrays as function parameters

[Sherif Ramadan]

I might be off here, but I believe the issue with that is that it's a
performance problem. You would have to check each key and function
parameter for a match, which would be slow.

You can, however, achieve what you're after just by using an array without
any packing/unpacking.

function foo(Array $args) {

// Expected arguments
$default = ["name" => null, "birthday" => null];
// Get actual arguments
$input = array_intersect_key($args, $default) + $default; // final

if (!isset($input['name'])) {
// ohnoes you forgot your name
}

if (!isset($input['birthday'])) {
// ohnoes you forgot your birthday
}

// otherwise use $Input['name'] and $input['birthday'] here...

}

On Sat, Mar 14, 2020 at 10:43 AM Midori Koçak  wrote:

> Dear Internals,
>
> I would like to as you a question. I know that it is possible to use an
> array to function parameters like: function(...array); But this method is
> not working when the array is associative.
>
> Would not be fine if an array like ['param1'=>'value', 'param2' => 'value']
> would be used in a function like function(param1, param2) regardless of the
> order?
>
> I think it would make our lives is easier. I'd be also happy if you know if
> there is more effective method to achieve the same result.
>
> Thanks,
> Midori
>

Re: [PHP-DEV] Array max size

[Sherif Ramadan]

Right, and therein lies the problem. No one has ever defined this behavior.
As such, one cannot document what has never been defined.

What you're describing is UNdefined. Undefined things cannot be documented.


On Wed, Aug 1, 2018, 3:46 PM Marcos Passos 
wrote:

> *The point is not about the possibility of crossing the limit of the
> array, but the need for a definition so one can design a method or function
> whose behavior aligns with the array capabilities. This need, in fact,
> became more noticeable from a design point of view since the introduction
> of the iterable pseudo-type.
>
>
>
> 2018-08-01 16:44 GMT-03:00 Marcos Passos :
>
>> It looks like the limit I mentioned, used by some functions, is
>> architecture-dependent:
>> https://github.com/php/php-src/blob/master/Zend/zend_types.h#L288
>>
>> Also, that's such a ridiculously large number for the vast majority of
>>> people using PHP that hardly anyone ever runs into this limit.
>>
>>
>> The point is not about the possibility of crossing the limit of the
>> array, but the need for a definition is one to design a method or function
>> whose behavior aligns with the array capabilities. This need, in fact,
>> became more noticeable from a design point of view since the introduction
>> of the iterable pseudo-type.
>>
>> No one ever said "this is what will happen if a PHP array exceeds 
>>> size". Until someone does that, I cannot document it.
>>
>>
>> I cannot disagree more with this statement.
>>
>> - Marcos
>>
>> 2018-08-01 16:29 GMT-03:00 Sherif Ramadan :
>>
>>> It's undocumented, because it's considered undefined behavior. PHP
>>> arrays implicitly store the number of elements internally as an unsigned 32
>>> bit integer (regardless of architecture). This means that (technically) you
>>> can't create an array with more than ((2**31) - 1) elements (or
>>> 2,147,483,647 elements). However, PHP won't actually attempt to stop you
>>> from doing this! The problem is, once you exceed these number of elements,
>>> the integer will overflow, causing undefined behavior (all kinds weird
>>> bugs). So we cannot document behavior that was never defined. No one ever
>>> said "this is what will happen if a PHP array exceeds  size". Until
>>> someone does that, I cannot document it. Also, that's such a ridiculously
>>> large number for the vast majority of people using PHP that hardly anyone
>>> ever runs into this limit.
>>>
>>>
>>>
>>>
>>> On Wed, Aug 1, 2018 at 2:42 PM Marcos Passos 
>>> wrote:
>>>
>>>> Whenever you look for more information about the maximum size of an
>>>> array,
>>>> you find someone saying that "PHP arrays do not have a maximum size, but
>>>> the amount of memory available". However, I could not find any excerpt
>>>> in
>>>> PHP documentation that supports that.
>>>>
>>>> Even if the engine imposes no hard limit on the size of an array, in
>>>> fact,
>>>> there an inherent limit that is assumed by some functions, and that is
>>>> what
>>>> I would like to suggest making explicit on the documentation. The lack
>>>> of
>>>> this definition leads to inconsistencies and leaves several open
>>>> questions,
>>>> including:
>>>>
>>>>- If no limit exists, then it's conceptually possible to have an
>>>> array
>>>>with *PHP_INT_MAX + 1* elements. In that sense, what would be the
>>>> return
>>>>of the *\count()*?
>>>>- The function *range* validates the size of the resulting range
>>>> against
>>>>the maximum size of the hash table (defined internally as
>>>> *HT_MAX_SIZE*),
>>>>and throw an error if it exceeds that value. Is that the limit?
>>>>- he function *array_fill*, in contrast, does not rely on
>>>> *HT_MAX_SIZE*
>>>>for validating the size of the result. But, why?
>>>>- The documentation says that omitting the third parameter of
>>>>array_split is equivalent to \count($array). If the maximum number
>>>>representable in PHP is *PHP_INT_MAX*, is the max size the same as
>>>>*PHP_INT_MAX*?
>>>>
>>>> There are other examples, but I think these are enough to make the
>>>> point.
>>>>
>>>> My understanding is that the conceptual limit is *PHP_INT_MAX*, as
>>>> there is
>>>> no way to represent the size above this value. If so, the interval that
>>>> represents all possibles indexes for an array is defined as *0 <= index
>>>> <=
>>>> PHP_INT_MAX -1*. That definition aligns with all functions that support
>>>> negative length as *-PHP_INT_MAX* is equivalent to the start of the
>>>> array.
>>>>
>>>> Could you guys please share your thoughts on this topic?
>>>>
>>>
>>
>

Re: [PHP-DEV] Array max size

[Sherif Ramadan]

It's undocumented, because it's considered undefined behavior. PHP arrays
implicitly store the number of elements internally as an unsigned 32 bit
integer (regardless of architecture). This means that (technically) you
can't create an array with more than ((2**31) - 1) elements (or
2,147,483,647 elements). However, PHP won't actually attempt to stop you
from doing this! The problem is, once you exceed these number of elements,
the integer will overflow, causing undefined behavior (all kinds weird
bugs). So we cannot document behavior that was never defined. No one ever
said "this is what will happen if a PHP array exceeds  size". Until
someone does that, I cannot document it. Also, that's such a ridiculously
large number for the vast majority of people using PHP that hardly anyone
ever runs into this limit.




On Wed, Aug 1, 2018 at 2:42 PM Marcos Passos 
wrote:

> Whenever you look for more information about the maximum size of an array,
> you find someone saying that "PHP arrays do not have a maximum size, but
> the amount of memory available". However, I could not find any excerpt in
> PHP documentation that supports that.
>
> Even if the engine imposes no hard limit on the size of an array, in fact,
> there an inherent limit that is assumed by some functions, and that is what
> I would like to suggest making explicit on the documentation. The lack of
> this definition leads to inconsistencies and leaves several open questions,
> including:
>
>- If no limit exists, then it's conceptually possible to have an array
>with *PHP_INT_MAX + 1* elements. In that sense, what would be the return
>of the *\count()*?
>- The function *range* validates the size of the resulting range against
>the maximum size of the hash table (defined internally as
> *HT_MAX_SIZE*),
>and throw an error if it exceeds that value. Is that the limit?
>- he function *array_fill*, in contrast, does not rely on *HT_MAX_SIZE*
>for validating the size of the result. But, why?
>- The documentation says that omitting the third parameter of
>array_split is equivalent to \count($array). If the maximum number
>representable in PHP is *PHP_INT_MAX*, is the max size the same as
>*PHP_INT_MAX*?
>
> There are other examples, but I think these are enough to make the point.
>
> My understanding is that the conceptual limit is *PHP_INT_MAX*, as there is
> no way to represent the size above this value. If so, the interval that
> represents all possibles indexes for an array is defined as *0 <= index <=
> PHP_INT_MAX -1*. That definition aligns with all functions that support
> negative length as *-PHP_INT_MAX* is equivalent to the start of the array.
>
> Could you guys please share your thoughts on this topic?
>

Re: [PHP-DEV] C++-like function-try-block proposal

[Sherif Ramadan]

On Sat, Dec 2, 2017 at 3:44 PM, Alexei Gerasimov 
wrote:

>
>
> > Let's not forget PHP 5 has been around for over a decade before PHP 7
> even
> > showed up. There are still a lot of old code basis that've been running
> in
> > PHP 5 for years. And for large code basis with deep rooted legacy, it is
> no
> > short order to make the leap. Change for the sake of change won't help
> that.
>
> I lost it here. I'm proposing a backward-compatible change, so why speak of
> legacy and existing codebases?
>


There's no argument that the change is not forward-compatible. I'm merely
pointing out the burden of adding new language features. This is not to
deter from adding them, but to caution against excess. There is a cost to
learning a new language feature, updating its documentation, considering
its trade offs in software design, etc... Part of this cost is shared
between those who maintain PHP and those who use PHP.

My statements here are intended to be cautionary, not dissuasive.

Re: [PHP-DEV] C++-like function-try-block proposal

[Sherif Ramadan]

On Sat, Dec 2, 2017 at 3:08 PM, Alexei Gerasimov 
wrote:

>
> I don't think we should be worried about changes _other_ projects would
> have to make to cope up with language evolution lest it becomes an
> (unnecessary and surrogate) obstacle. My vision is that if some
> company/group produces an IDE, it is but natural to expect them to be ready
> to adapt to language changes.
>
>
I agree, because our parser is open source like everything else in PHP.
IDEs can likely just generate one from ours with minimal effort. However,
it isn't the IDEs I'm worried about. It's the end-users of the language
that will struggle the most. Let's not forget PHP 5 has been around for
over a decade before PHP 7 even showed up. There are still a lot of old
code basis that've been running in PHP 5 for years. And for large code
basis with deep rooted legacy, it is no short order to make the leap.
Change for the sake of change won't help that.

Re: [PHP-DEV] C++-like function-try-block proposal

[Sherif Ramadan]

I think we get this "I want to make PHP more like " thing more
often than any other language change proposals. I'm not strictly opposed to
the idea of borrowing from other languages. Though when the thesis
statement is almost exclusively about making PHP feel more like  than anything else I'd rather not entertain the idea further.

I agree with Nikita that this feature in C++ adds no intrinsic value to
PHP. I'm never overly excited about purely syntactic sugar changes in PHP.
We've already changed so much of the language in PHP 7 that I'm finding
some people struggling with keeping up with PHP 5 - 7 migration paths (and
I'm speaking from first hand experience having to deal with one myself at
work).

I'd like to see an RFC that demonstrates a stronger use case than "avoiding
one level of indentation and ", however. Kind of erring
on the side of +0 with Sara here.

On Sat, Dec 2, 2017 at 1:13 PM, Andreas Hennings 
wrote:

> So to summarize, this feature would save us brackets and one indentation
> level.
> Saving an indentation level can be quite useful to reduce a git commit
> footprint.
>
> On the other hand, it might confuse some people. It would blur the concept
> of a function body scope, and thus the mental model of how the language
> works.
> E.g. are local variables and parameters shared between the try {} and the
> catch {} block?
>
> It would also mean that userland PHP parsers and IDEs need to support the
> syntax.
>
> So personally I am undecided or skeptical. It does feel alien to me.
> Usually if I want to avoid the extra indentation, I will put the try {}
> part into a separate function.
> But this is just me.
>
>
> On 2 December 2017 at 14:27, Alexei Gerasimov 
> wrote:
>
> > > > I did (using this e-mail address), and got the message: "The user has
> > been created and the password was sent by email." However, I did not
> > receive any e-mail with the password.
> > >
> > > Sorry for the trouble, seems like nobody tested the sign up process
> > after the server migration yet. It seems like the e-mail sender
> > configuration is missing.
> > >
> > >
> > > Unfortunately, I don't know the right config, so I can't simply fix it,
> > but I've sent a message to Hannes, he probably knows.
> >
> > Any update? The reset password feature of wiki.php.net doesn't work
> > either, I receive no e-mail.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] rfc concepts

[Sherif Ramadan]

There have already been several such proposals made in past years, and
discussed at length here on the mailing list.

See C# Style Accessors past RFC:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
and alternatives:
https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax


Since PHP 7 already supports scalar type hints and strict mode, as well as
magic getters/setters, pretty much all of your aforementioned concepts are
already possible in PHP with a bit of boiler plate. The declarative
accessors obviously have some benefits like less verbosity and more concise
syntax, but we've been down this road before in the past and I'd suggest
reading the discussions around those RFCs, with similar ideas, which were
declined or withdrawn and coming up with a more constructive approach if
you want it to gain any critical mass. It's going to be a tough sell if you
just come back with the same approach.

On Thu, Apr 13, 2017 at 9:40 PM, Kelt Dockins  wrote:

> Hi everybody,
>
>
> I've been using php for many years now and it really is a great language.
> My friend and I were talking about additional things we would want in php -
> sort of like a wishlist. I came up with 3 things that I think would make
> php even more awesome and I wanted to share these concepts with this list
> and I'd love to get feedback. I haven't done any c programming in years but
> I'd be open to working on these concepts if enough people wanted them.
>
>
>
> 1. use strict mode
>
>
> ```
>
> class Bar { }
>
>
> class Foo
>
> {
>use strict;
>
> }
>
>
> $bar = new Bar;
>
> $bar->thing = 1; // no problem
>
>
> $foo = new Foo;
>
> $foo->thing = 1; // throws error because thing attribute does not
> exists
>
> ```
>
>
>
> 2. type hinting class properties
>
>
> ```
>
> class Foo
>
> {
>public $thing : int;
>
> }
>
>
> $foo = new Foo;
>
> $foo->thing = 1;   // works fine
>
> $foo->thing = 'string';  // throws Typehint
>
> ```
>
>
> 3. auto properties
>
>
> ```
>
> class Foo
>
> {
>
>private $thing1 {
>
>   get, set
>
>};
>
>
>private $thing2 {
>
>   get
>
>};
>
>
>private $thing3 {
>
>   set
>
>};
>
> }
>
>
> $foo = new Foo;
>
> $foo->thing1 = 'asdf';
>
> echo $foo->thing1;   // echos 'asdf'
>
>
> $foo->thing2 = 'asdf';   // throws error because no setter
>
>
> $foo->thing3 = ''asdf';  // sets thing3
>
> echo $foo->thing3;  // throws error because no getter
>
> ```
>
>
> I'd love to hear what you all have to say about these things. Thanks in
> advance for your feedback and time!
>
>
> - Kelt
>

Re: [PHP-DEV] Unexpected results from constant folding

[Sherif Ramadan]

I would definitely vote C as well. PHP 7's behavior makes even less sense
than PHP 5 in this case.

On Tue, Mar 14, 2017 at 10:43 PM, Sara Golemon  wrote:

> This comes in thanks to my old friend Fred Emmott on the HHVM project:
> https://3v4l.org/vUHq3
>
> class Foo {
> const A = 1 << 0;
> const B = self::A | self::C;
> const C = 1 << 1;
>
> }
>
> class Bar extends Foo {
> const A = 1 << 2;
> const C = 1 << 3;
> }
>
> var_dump(decbin(Bar::B));
> // HHVM result: 11
> // PHP5 result: 1100
> // PHP7 result: 1001
>
> HHVM's result is clearly correct as `self::` refers to the defining
> class and so should bind to Foo's values for A and C.
> PHP5's result is at least rationally viable, although it effectively
> redefines `self::` to the semantics of `static::` just for this case.
> PHP7's result is... well, I can imagine how it occurs, but it can't be
> called correct by any measure.
>
> Opinions on the right thing to do here?
> a) Leave it alone because it's been that way since 7.0
> b) Revert to php5 behavior
> c) Match HHVM's behavior
>
> I vote C because that's the semantic meaning of self:: and we should
> respect PHP's own language rules.
> Barring that, I'd be okay with B as it's at least explainable without
> too much mental gymnastics.
> I straight up veto A.  That's just cray-cray.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Type variants

[Sherif Ramadan]

If the problem you're trying to solve pertains to object state that I have
no idea how this proposal hopes to achieve that. You can readily control
object state in PHP without the need for declarative types (e.g. magic
getters/setters). Not seeing how this proposal improves or even achieves
such a thing. I think you're trying desperately to find a problem that is
fitting of the proposal whereas all real-world problems that exist under
this domain are already solved problems.

On Sun, Mar 12, 2017 at 4:17 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:

> 2017-03-12 13:03 GMT+05:00 Sherif Ramadan :
>
> how it pertains to this discussion
> >
>
> This is example of type matching from my first message.
>
> I'm not sure what that has to do with inheritance
> >
>
> Yes, this is not related with inheritance. But order can be ready for
> checkout or can not. This is a variant of valid object state. If we could
> have a tool to describe that and check later, it would be useful.
>

Re: [PHP-DEV] Type variants

[Sherif Ramadan]

I'm not sure what that has to do with inheritance exactly or how it
pertains to this discussion. This is an implementation detail.

On Sun, Mar 12, 2017 at 3:47 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:

> 2017-03-12 12:19 GMT+05:00 Sherif Ramadan :
>
> > Which requirements are those exactly?
> >
>
> An order should have count of products > 0 and date and address filled
> before checkout procedure.
>

Re: [PHP-DEV] Type variants

[Sherif Ramadan]

Which requirements are those exactly?


On Sun, Mar 12, 2017 at 3:15 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:

> 2017-03-12 12:03 GMT+05:00 Sherif Ramadan :
>
>> You could have an abstract classes implement the interface and extend
>> from the abstract classes.
>>
>>
> Ok, could you give an example, how to check described requirements with
> interface?
>

Re: [PHP-DEV] Type variants

[Sherif Ramadan]

You could have an abstract classes implement the interface and extend from
the abstract classes.

On Sun, Mar 12, 2017 at 1:57 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:

> 2017-03-12 11:41 GMT+05:00 Sherif Ramadan :
>
> > Yea, but how's that an improvement over using an interface?
> >
> >
> How can I check if an order is ready for checkout with interface? The
> difference is in property values, not in presence of methods.
>

Re: [PHP-DEV] Type variants

[Sherif Ramadan]

Yea, but how's that an improvement over using an interface?

On Sun, Mar 12, 2017 at 1:38 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:

> > Example with Rectangle and Square IMO is an example of bad naming in this
> case.
>
> I used this example because this is known problem of inheritance. Type
> variants solve this problem. Square is a particular case (variant) of
> Rectangle.
>
> > PHP already has horizontal inheritance. They're called traits. How is
> this an improvement in anyway?
>
> Trait is just reusable implementation. I suggest type matching. This is
> extension of type hinting. It can be used in all cases where we need to
> check if an object matches some criterias before continue operation. It is
> a kind of defensive programming and a replacement for many 'if-throw'
> constructions.
>

Re: [PHP-DEV] Type variants

[Sherif Ramadan]

PHP already has horizontal inheritance. They're called traits.

How is this an improvement in anyway?

On Sat, Mar 11, 2017 at 1:36 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:

> Hello. I have an idea which seems rather useful. I would like to know your
> opinion,
>
> Let's say we have class Rectangle and need to have class Square which will
> be used in some operations. We don't need any rectangle, this must be only
> square.
> What if we could describe a type which is the same as another type but have
> some restrictions for properties?
>
> Something like this:
>
> class Rectangle
> {
> private $x;
> private $y;
> private $width;
> private $height;
>
> public function __construct($x, $y, $width, $height)
> {
> $this->x = $x;
> $this->y = $y;
> $this->width = $width;
> $this->height = $height;
> }
> }
>
> class Square variant of Rectangle
> {
> public function __match()
> {
> if ($this->width != $this->height) {
> return ['width' => 'Width and height have to be the same'];
> }
>
> return true;
> }
> }
>
> function drawSquare(Square $square)
> {
> // ...
> }
>
> $rectangle = new Rectagle(0, 0, 10, 10);
> drawSquare($rectangle);
>
> When drawSquare() is called, the check 'instanceof' is performed. It calls
> magic method __match().
> If __match() does not return true, it throws an exception with the data
> returned:
> 'Order does not match OrderForCheckout. Reason: ...'.
>
>
> Technically, we don't have method __match() in $rectangle object. So it can
> be static, or a proxy object can be created here.
>
> The second variant can be extended.
> We may not to inherit implementation of methods, and describe another
> interface instead, for example new object can be read only.
>
> class Square variant of Rectangle
> {
> public function ___match()
> {
> // ...
> }
>
> public function getWidth()
> {
> return parent::getWidth();
> }
> }
>
> With some changes in syntax it can be defined in this way:
>
> class Square variant of Rectangle
> {
> ...
>
> getWidth: base::getWidth;
> }
>
>
> This is like inheritance, but semantically differs a little.
> Inheritance has vertical direction, type variants have horisontal one.
> Also type variants have an access for all methods and properties of base
> class, even for private.
>
>
> Another example. Let's say we have an order checkout process which is
> splitted into 3 steps - cart for products, date page, delivery address
> page.
> This is not an input validation, this is a validation in business logic.
>
> class Order
> {
> public $products;
> public $date;
> public $address;
> }
>
> class OrderForCheckout variant of Order
> {
> public function __match()
> {
> $errors = [];
> if (empty($this->products)) {
> $errors['products'] = 'Product list is empty';
> }
> if ($this->date === null) {
> $errors['date'] = 'Date is not selected';
> }
> if (empty($this->products)) {
> $errors['address'] = 'Address is not selected';
> }
>
> return (empty($errors) ? true : $errors);
> }
> }
>
> public function checkout(OrderForCheckout $order)
> {
> ...
> }
>
> $order = findCurrentOrder();
> checkout($order);  // if $order does not match requirements, the exception
> will be thrown
>

[PHP-DEV] [Only a test] Please ignore

[Sherif Ramadan]

This is only a test. Please ignore. Thanks.

Re: [PHP-DEV] please excuse my forum crosspost, please do read this when you have some time.

[Sherif Ramadan]

On Wed, Mar 1, 2017 at 3:30 PM, Rene Veerman <
rene.veerman.netherla...@gmail.com> wrote:

> exec-sum : introducing a new URL notation scheme
>
> 2 examples :
>
> example 1 :
>
> http://localhost/tarot(deck'Original-Rider-Waite
> ',reading'3-Cards')/music(youtubePlaylist'ABCDEFG')
>
> parameters decoded from the current website location (URL) =
>
> array(2) {
> ["tarot"]=>array(2) {
> ["deck"]=>string(20) "Original-Rider-Waite"
> ["reading"]=>string(7) "3-Cards"
> }
> ["music"]=>array(1) {
> ["youtubePlaylist"]=>string(7) "ABCDEFG"
> }
> }
>
>
>
>
>
> http://localhost/jsonViewer(url'base64aHR0cDovL3NlZHVjdGl2ZWFw
> cHMuY29tL2pzb24ucGhwP2ZpbGU9L2hvbWUvcmVuZS9kYXRhLmpzb24mdmVy
> c2lvbj1jb25kZW5zZWQ=
> ')
>
> parameters decoded from the current website location (URL) =
>
> array(1) {
> ["jsonViewer"]=>array(1) {
> ["url"]=>string(76)
> "http://seductiveapps.com/json.php?file=/home/rene/data.
> json&version=condense"
> }
> }
>
>
>
>
>
> for more details, see :
> https://forums.digitalpoint.com/threads/introducing-a-new-
> url-notation-scheme.2797191/
>
> due to mailinglist limitations, i can not repost the content here.
> but you are most welcome to comment on it here, i'll check my mail in about
> 12 hours from now.
>



Is there even a thesis statement to this discussion?

Re: [PHP-DEV] number_format() = "-0.00"

[Sherif Ramadan]

I'm pretty sure this is covered by the language reference [
http://php.net/language.types.float] as per precision of floating point
numbers in PHP. Though I don't see much harm in adding a note with
references there to the documentation for number_format(), if that's what
you meant.

On Fri, Nov 25, 2016 at 3:21 AM, Craig Duncan  wrote:

> On 25 Nov 2016 08:11, "Rasmus Lerdorf"  wrote:
> >
> > This doesn't seem like a bug to me. Our floating point is all IEEE 754
> and as per IEEE 754 -0.00 is the correct and expected result here.
>
> I've just read the link below and I'm inclined to agree on the technical
> reasoning.
> https://en.wikipedia.org/wiki/Signed_zero
> I'm not sure of its practical usage in PHP, I think most of our developers
> would expect "0.00", but bring consistent with IEEE 754 makes sense.
>
> Shall I add a note to the docs about this expected behaviour instead?
>

Re: [PHP-DEV] PDOStatement::activeQueryString()

[Sherif Ramadan]

I really doubt this method will prove useful in practice for the use case
you mention, and for a number of a reasons.

1) The name is misleading (there is no real query string in the case of
native prepared statements - the SQL and data are always separate)
2) You would have to execute the statement first in order to get the debug
information you're looking for (meaning that if the execution of the
statement fails for any reason other than what the SQL parser can detect,
there is no useful debug information from this method)
3) This only works if you use emulated prepares, which creates a whole new
stream of complaints by people who don't understand the difference


I don't think the real problem is seeing the entire query assembled with
the parameters filled in, because the buggy part would never be the actual
parameter values themselves. If there is a bug in the SQL, it's typically
the result of a syntax error, or constraint violation, or name error. I
sincerely doubt this method would prove useful in debugging in any of those
things. The server-side error messages from the DBMS would prove more
useful in those cases.

In other words, I believe people would get more useful debug information by
just turning off emulated prepares, putting PDO into Exception error mode,
and looking at the error information provided by the DBMS since with
server-side prepares you get failure upon preparing, and before execution
even begins, such that parameters are no longer the actual concern for
error.

On Thu, Oct 13, 2016 at 2:42 PM, Matteo Beccati  wrote:

> Hi,
>
> On 13/10/2016 19:59, Adam Baratz wrote:
> > I'd like to add a new method that would return the prepared statement as
> it
> > was executed. It's common for people I work with to want this info for
> > debugging, but you can't get it from userland. The functionality is
> similar
> > to, but distinct from PDOStatement::debugDumpParams().
> >
> > I figure it's always easier to discuss proposals alongside real code:
> > https://github.com/php/php-src/pull/2159
> >
> > Please let me know what you think, if an RFC would be appropriate, or
> what.
>
> To be perfectly honest, my wish is that EMULATE_PREPARES could be
> deprecated and removed and I see something this as a step in the
> opposite direction.
>
> That said, I think a tiny RFC that explains what's the problem you are
> trying to solve, the current issue and possible other solutions would be
> very welcome. This is an API change and most likely will require all the
> drivers to be adapted.
>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Sherif Ramadan]

On Sun, Sep 11, 2016 at 4:47 AM, Tony Marston 
wrote:

> Sent: Saturday, September 10, 2016 7:47 PM
> >To: Tony Marston ; internals@lists.php.net
> >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
> composer/pickle
>
>
> Then I suggest that those who are so anxious to see of death of PEAR/PECL
> should be forced to provide a viable alternative first. Otherwise they
> would be just like those stupid politicians who try to force commuters out
> of their private cars and into public transport without realising that the
> existing public transport system is NOT a viable replacement and is
> incapable of taking on the extra load.
>
>

I just want to say that PEAR as a source repository, has been dead for
quite some time. It's filled with outdated code that has hardly seen any
maintenance in years, and nobody really contributes to it anyway.

PEAR/PECL as a package manager has historically had little utility to the
average user apart from installing those PECL extensions which aren't
packaged by a particular user's distribution repository. Certainly hasn't
had any real viability in years. Trying to replace something that's
inherently non-viable with a viable-alternative seems like a pretty moot
point.

[PHP-DEV] Test

[Sherif Ramadan]

Just testing that the mailing list is still working. Please ignore.

Re: [PHP-DEV] Password_hash salt generation refactor

[Sherif Ramadan]

If I'm understanding this correctly, this change doesn't effect actual
behavior, right? It's just taking advantage of reusing code for
random_bytes / random_int ?

If that is true I don't think it much matters whether the change goes
through 7.0 or 7.1 since it has no real end-user impact.

On Sun, Oct 18, 2015 at 6:59 PM, Anthony Ferrara 
wrote:

> All,
>
> With PHP 7 comes random_bytes and random_int. This duplicates some of
> the logic internally that password_hash uses to generate its salt.
>
> I would like to refactor this to unify generation. I've opened a PR
> against master: https://github.com/php/php-src/pull/1585
>
> I don't feel comfortable pulling against 7 this far into RC status.
> Perhaps wait until after it goes gold? Or should this target 7.1? It's
> not a big deal in either direction. Though it does add a side-effect,
> where if it can't gather enough entropy it will throw an exception and
> return failure (where prior it would simply make a "best effort".
>
> Thoughts?
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] New function proposal

[Sherif Ramadan]

I think this is the most awesomest fantastical idea since sliced bread.

+~0

On Thu, Oct 8, 2015 at 11:05 AM, Mattias Gonzalez  wrote:

> I wanted to propose the "var_die($var)" functionallity.
> My mates and i use a lot var_dump($var);die;
>
> Since die() wont print an array just a string, i think it´ll be very
> useful.
>
> It should do the var_dump($var);and die();
>
> what do you think?
>

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Sherif Ramadan]

I get that it exists. I'm asking what is the usefulness of having a
function that tells you the variable is null? In theory this sounds great
and is actually very doable by checking the symbol table for the hash.
However, in practice, who actually has a use for this? Null is a special
value in PHP, so if you're assigning it to a variable explicitly you should
already know you've initialized that variable and can safely rely on if ($x
=== null) in your code.

I'm not confused about the differences. I'm questioning the usefulness of
such a function.

On Tue, Aug 25, 2015 at 11:18 PM, Scott Arciszewski 
wrote:

> Because $x exists.
>
> https://3v4l.org/kUJtP
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises
>
>
> On Tue, Aug 25, 2015 at 11:16 PM, Sherif Ramadan
>  wrote:
> > Yes, because all undefined variables in PHP are implicitly null. As far
> as
> > PHP is concerned, if it's null, it's by definition _not defined_. Also,
> > still not seeing where a NOTICE is involved here? Those functions never
> give
> > errors.
> >
> > What is the usefulness of a function that merely returns true when a
> > variable is null?
> >
> > On Tue, Aug 25, 2015 at 11:13 PM, Scott Arciszewski  >
> > wrote:
> >>
> >> On Tue, Aug 25, 2015 at 11:11 PM, Sherif Ramadan
> >>  wrote:
> >> > That's exactly what isset() does. isset/empty never raise errors.
> >> >
> >> > On Tue, Aug 25, 2015 at 11:09 PM, Scott Arciszewski
> >> > 
> >> > wrote:
> >> >>
> >> >> Hi everybody,
> >> >>
> >> >> Would anyone be interested in adding another helper like
> >> >> isset()/empty() simply called exists() which would return true if the
> >> >> variable is defined in the current scope (i.e. without raising an
> >> >> E_NOTICE)?
> >> >>
> >> >> It should be a simple change to add this function but it's too late
> >> >> for 7.0 so, if there is any interest, I would respectfully put it off
> >> >> until 7.1.
> >> >>
> >> >> Scott Arciszewski
> >> >> Chief Development Officer
> >> >> Paragon Initiative Enterprises <https://paragonie.com>
> >> >>
> >> >> --
> >> >> PHP Internals - PHP Runtime Development Mailing List
> >> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >> >>
> >> >
> >> http://phpsadness.com/sad/28
> >> https://3v4l.org/2vrKG
> >>
> >> Not quite.
> >>
> >> Scott Arciszewski
> >> Chief Development Officer
> >> Paragon Initiative Enterprises <https://paragonie.com>
> >
> >
>

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Sherif Ramadan]

Yes, because all undefined variables in PHP are implicitly null. As far as
PHP is concerned, if it's null, it's by definition _not defined_. Also,
still not seeing where a NOTICE is involved here? Those functions never
give errors.

What is the usefulness of a function that merely returns true when a
variable is null?

On Tue, Aug 25, 2015 at 11:13 PM, Scott Arciszewski 
wrote:

> On Tue, Aug 25, 2015 at 11:11 PM, Sherif Ramadan
>  wrote:
> > That's exactly what isset() does. isset/empty never raise errors.
> >
> > On Tue, Aug 25, 2015 at 11:09 PM, Scott Arciszewski  >
> > wrote:
> >>
> >> Hi everybody,
> >>
> >> Would anyone be interested in adding another helper like
> >> isset()/empty() simply called exists() which would return true if the
> >> variable is defined in the current scope (i.e. without raising an
> >> E_NOTICE)?
> >>
> >> It should be a simple change to add this function but it's too late
> >> for 7.0 so, if there is any interest, I would respectfully put it off
> >> until 7.1.
> >>
> >> Scott Arciszewski
> >> Chief Development Officer
> >> Paragon Initiative Enterprises <https://paragonie.com>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> http://phpsadness.com/sad/28
> https://3v4l.org/2vrKG
>
> Not quite.
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com>
>

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Sherif Ramadan]

That's exactly what isset() does. isset/empty never raise errors.

On Tue, Aug 25, 2015 at 11:09 PM, Scott Arciszewski 
wrote:

> Hi everybody,
>
> Would anyone be interested in adding another helper like
> isset()/empty() simply called exists() which would return true if the
> variable is defined in the current scope (i.e. without raising an
> E_NOTICE)?
>
> It should be a simple change to add this function but it's too late
> for 7.0 so, if there is any interest, I would respectfully put it off
> until 7.1.
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Notice on non existing array key (on a boolean)

[Sherif Ramadan]

Hmmm... I'm not really sure whether to consider this a language change or
not. I mean no syntax has changed, but sure it does break BC because of the
new notice. I'm really dubious about whether or not this demands an RFC.
I've seen more sweeping changes make it into a release with less discussion
and no RFC.

AllenJB, does this work the same for FAD and object properties? I haven't
tested your pull locally yet, but it looks good to me. If this covers cases
for both myFunc()['foo'] and $obj->prop['foo'] where neither is an array
then I think it's definitely worth getting into 7.0.0, but I'll have to
checkout your pull later tonight and test it a bit more. It looks like
based on the discussion you've pretty much covered all of my major concerns
with isset(), each(), and some of the other problems I saw from the PHP 5
attempts at fixing it.

Also, thanks for taking the time to put this together and fix all the tests!

On Tue, Aug 25, 2015 at 12:02 PM, AllenJB  wrote:

> I have a pull request pending on this bug:
> https://github.com/php/php-src/pull/1269
>
> It's been discussed before ("Array dereferencing of scalars", 10th June
> 2015 - I'm pretty sure it was discussed at least once more since then too)
> and I was basically told it would require an RFC to get it accepted.
>
> Unfortunately the RFC window had basically closed at that time (and work
> got busy shortly after), so now I've been waiting until 7.0 is clear (as
> well as me having the time to finish drafting the RFC).
>
> AllenJB
>
>
>
> On , Sherif Ramadan wrote:
>
>> Hey Nicolai,
>>
>> You're right. The notice is triggered by array_push behavior only, which
>> means that $x = true; echo $x['foo']; doesn't trigger the notice, which is
>> the same as your code above. Only write operations have historically
>> resulted in this notice.
>>
>> I would agree that providing the notice would help someone debugging
>> potentially buggy code like this. Not sure if this is something we can
>> squeeze into 7.0.0 release at this point, but I would consider it a bug
>> fix
>> with BC rather than something that should be subject to current feature
>> freeze.
>>
>>
>>
>> On Tue, Aug 25, 2015 at 9:35 AM, Nicolai Scheer > >
>> wrote:
>>
>> Hi all,
>>>
>>> I'd expect the following code to throw a notice/warning:
>>>
>>> $x = true;
>>> $y = $x['foo'];
>>>
>>> It executes completely silently.
>>> $y is NULL afterwards, which is expected, since the right hand side of
>>> the assignment is undefined.
>>>
>>> If $x was an array (e.g. empty array), a E_NOTICE would be emitted.
>>>
>>> Can anyone shed a light on this behaviour? If accessing non existing
>>> array keys is worth a notice, shouldn't accessing an array index on a
>>> non array be worth a notice as well (maybe even a warning)?
>>>
>>> The other way round emits a warning (i.e. writing to an array key on a
>>> non array):
>>>
>>> $x = true;
>>> $x['foo'] = 'bar';
>>>
>>> Warning: Cannot use a scalar value as an array ...
>>>
>>> Thanks for any insight,
>>>
>>> greetings
>>>
>>> Nico
>>>
>>
>
>

Re: [PHP-DEV] Notice on non existing array key (on a boolean)

[Sherif Ramadan]

Hey Nicolai,

You're right. The notice is triggered by array_push behavior only, which
means that $x = true; echo $x['foo']; doesn't trigger the notice, which is
the same as your code above. Only write operations have historically
resulted in this notice.

I would agree that providing the notice would help someone debugging
potentially buggy code like this. Not sure if this is something we can
squeeze into 7.0.0 release at this point, but I would consider it a bug fix
with BC rather than something that should be subject to current feature
freeze.



On Tue, Aug 25, 2015 at 9:35 AM, Nicolai Scheer 
wrote:

> Hi all,
>
> I'd expect the following code to throw a notice/warning:
>
> $x = true;
> $y = $x['foo'];
>
> It executes completely silently.
> $y is NULL afterwards, which is expected, since the right hand side of
> the assignment is undefined.
>
> If $x was an array (e.g. empty array), a E_NOTICE would be emitted.
>
> Can anyone shed a light on this behaviour? If accessing non existing
> array keys is worth a notice, shouldn't accessing an array index on a
> non array be worth a notice as well (maybe even a warning)?
>
> The other way round emits a warning (i.e. writing to an array key on a
> non array):
>
> $x = true;
> $x['foo'] = 'bar';
>
> Warning: Cannot use a scalar value as an array ...
>
> Thanks for any insight,
>
> greetings
>
> Nico
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Overflow checks and integral vars comparison

[Sherif Ramadan]

Hey Rowan,

Yup, I get it now. Sorry for the confusion.

I actually remember fixing a similar bug in pdo_sqlite a while back where
casting/translation between the two sizes caused such an issue. So I think
this would be pretty helpful.

On Sun, Aug 23, 2015 at 6:28 PM, Rowan Collins 
wrote:

> On 22/08/2015 02:38, Sherif Ramadan wrote:
>
>> I see. So you're not actually doing overflow checks then? Because at the
>> point you'd be checking this zend_long or size_t it could have already
>> overflowed or wrapped. The subject may have misled me to understand
>> differently.
>>
>
> I think I understand the confusion: you are thinking of overflow as
> something which happens *within* a type based on some operation (addition,
> multiplication, etc).
>
> Anatol is talking about overflows which occur when casting *between*
> types: a value of 2^33 can safely be passed around as a 64-bit integer, no
> overflow has occurred; but attempting to cast it to a 32-bit integer will
> immediately overflow the 32-bit integer.
>
> Since many PHP extensions are wrappers around libraries which may only
> deal in 32-bit types, this cast is common, necessitating range checks like
> the ones proposed.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Overflow checks and integral vars comparison

[Sherif Ramadan]

On Fri, Aug 21, 2015 at 6:22 AM, Anatol Belski 
wrote:

>
>
> > -Original Message-
> > From: Sherif Ramadan [mailto:theanomaly...@gmail.com]
> > Sent: Friday, August 21, 2015 12:00 PM
> > To: Anatol Belski 
> > Cc: Dmitry Stogov ; Xinchen Hui ;
> > Nikita Popov ; Pierre Joye ;
> > Bob Weinand ; Jakub Zelenka ; Matt
> > Wilmas ; PHP Internals  >
> > Subject: Re: [PHP-DEV] Overflow checks and integral vars comparison
> >
> > I think you're a little optimistic about how effective these macros
> would be for
> > overflow checks. Also, if we're talking ANSI C or C99, then size_t is
> always
> > unsigned, and as far as I know GCC 2.4 always treats it as such.
> > If we're trying to stick to C here anyway.
> >
> > As far as architecture specific stuff I would much rather rely on using
> the built-in
> > GCC overflow checks here https://gcc.gnu.org/onlinedocs/gcc/Integer-
> > Overflow-Builtins.html
> >
> Yes, this is a good idea as a further extension of such mechanics. However
> you're talking about a different topic that I've proposed now.
> > ... as they are much safer and likely going to be far more performant
> than doing
> > all these casts everywhere. Not to mention the fact that you can
> actually catch
> > the overflow at the actual arithmetic level, where it's safe, and
> hopefully be able
> > to rely on the ISA's overflow or carry bits. If we're trying to detect
> overflows or
> > wraps after the fact, you don't add much in the way of security. For
> example,
> > I'm not at all sure how (zlong) < (zend_long)INT_MIN will ever detect an
> > overflow.
> >
> What I'm talking about is detecting whether a variable of zend_long or
> size_t is in the safe range to be passed to a signature requiring int. This
> is quite a minimalistic start in this direction.
>

I see. So you're not actually doing overflow checks then? Because at the
point you'd be checking this zend_long or size_t it could have already
overflowed or wrapped. The subject may have misled me to understand
differently.


>
> Also please remember that there is not only GCC in the world. It is quite
> another topic to implement overflow checks portable ways, some intrinsics
> can be here of some help, too. But rather than hitting quite a global
> thing, I'd rather start on what is simple and is for sure an issue at least
> with some dependency libs.
>

Of course, but the ASM can also be ported to other architectures and
wrapped in #ifdef for non x86 and MSVC or other compilers, for example.
It's not impossible to achieve some sane degree of portability there. I see
Andrea already worked on some of this in zend_operators.h for example
https://github.com/php/php-src/blob/ee2e1691080dad2a3110107dd8bd02ee23b41fa0/Zend/zend_operators.h#L437

Of course, making integer overflow checks safe and efficient is by no means
easy on every given architecture, but surely we could aim to support at
least the broadest current architectures at first and fall back to C
overflow checks if necessary.

I agree with starting simple. I'm honestly not sure of the effectiveness of
what you're proposing to be honest, but maybe with a PR I'd be able to wrap
my head around it a little more.



>
> Regards
>
> Anatol
>
>

Re: [PHP-DEV] Overflow checks and integral vars comparison

[Sherif Ramadan]

I think you're a little optimistic about how effective these macros would
be for overflow checks. Also, if we're talking ANSI C or C99, then size_t
is always unsigned, and as far as I know GCC 2.4 always treats it as such.
If we're trying to stick to C here anyway.

As far as architecture specific stuff I would much rather rely on using the
built-in GCC overflow checks here
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

... as they are much safer and likely going to be far more performant than
doing all these casts everywhere. Not to mention the fact that you can
actually catch the overflow at the actual arithmetic level, where it's
safe, and hopefully be able to rely on the ISA's overflow or carry bits. If
we're trying to detect overflows or wraps after the fact, you don't add
much in the way of security. For example, I'm not at all sure how (zlong) <
(zend_long)INT_MIN will ever detect an overflow.

On Fri, Aug 21, 2015 at 5:40 AM, Anatol Belski 
wrote:

>
>
> > -Original Message-
> > From: Anatol Belski [mailto:anatol@belski.net]
> > Sent: Friday, August 21, 2015 11:38 AM
> > To: 'Sherif Ramadan' 
> > Cc: 'Dmitry Stogov' ; 'Xinchen Hui'  >;
> > 'Nikita Popov' ; 'Pierre Joye' <
> pierre@gmail.com>;
> > 'Bob Weinand' ; 'Jakub Zelenka' ;
> > 'Matt Wilmas' ; 'PHP Internals'
> > 
> > Subject: RE: [PHP-DEV] Overflow checks and integral vars comparison
> >
> > Hi Sherif,
> >
> > > -Original Message-
> > > From: Sherif Ramadan [mailto:theanomaly...@gmail.com]
> > > Sent: Friday, August 21, 2015 11:21 AM
> > > To: Anatol Belski 
> > > Cc: Dmitry Stogov ; Xinchen Hui ;
> > > Nikita Popov ; Pierre Joye
> > > ; Bob Weinand ; Jakub
> > > Zelenka ; Matt Wilmas ; PHP
> > > Internals 
> > > Subject: Re: [PHP-DEV] Overflow checks and integral vars comparison
> > >
> > > Maybe I'm missing something here, but how do these macros detect
> > > overflow exactly? If the check is done on the actual result and not
> > > the operands then it's not a good overflow check. Additionally, why
> > > wouldn't overflow checks be needed on 32-bit architecture, or any other
> > architecture for that matter?
> > > Integers can overflow there too.
> > >
> > Example code in simplexml_load_string()
> >
> > if (zend_parse_parameters(ZEND_NUM_ARGS(), "s|C!lsb", &data,
> &data_len,
> > &ce, &options, &ns, &ns_len, &isprefix) == FAILURE) {
> > return;
> > }
> >
> > If (ZEND_LONG_INT_OVFL(options)) {
> >  RETURN_FALSE;
> > }
> > If (ZEND_SIZE_T_INT_OVFL(data_len)) {
> >  RETURN_FALSE;
> > }
> >
> > docp = xmlReadMemory(data, data_len, NULL, NULL, options);
> >
> >
> > - on x86_64 - possible int overflow without check
> > - on ILP64 or i386 alike - no int overflow per se, so can be ommited
> >
> No int overflow with zend_long I wanted to say, so it's "if (0)" which is
> eliminated, but with size_t an overflow is still possible.
>
> > > On Fri, Aug 21, 2015 at 4:41 AM, Anatol Belski 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Resending this as missed internals at the start.
> > > >
> > > > I was lately rethinking some part of the 64-bit RFC, and also seeing
> > > > now Jakub's work on catching overflows in ext/openssl and Matt
> > > > Williams suggestions on it (which was going a bit more global over
> > > > it). So I came up with these macros with two goals
> > > >
> > > > - standardize the overflow checks
> > > > - do actualy checks only on architectures where it's needed
> > > > - simplify the checks where external libs (openssl, libxml, etc.)
> > > > use firm datatypes like int
> > > >
> > > > #if SIZEOF_INT == SIZEOF_ZEND_LONG
> > > > # define ZEND_LONG_INT_OVFL(zl) (0)
> > > > # define ZEND_LONG_INT_UDFL(zl) (0)
> > > > #else
> > > > # define ZEND_LONG_INT_OVFL(zlong) ((zlong) > (zend_long)INT_MAX) #
> > > > define
> > > > ZEND_LONG_INT_UDFL(zlong) ((zlong) < (zend_long)INT_MIN) #endif
> > > >
> > > > #define ZEND_SIZE_T_INT_OVFL(size) ((size) > (size_t)INT_MAX)
> > > >
> > > > So having it like
> > > >
> > &

Re: [PHP-DEV] Overflow checks and integral vars comparison

[Sherif Ramadan]

Maybe I'm missing something here, but how do these macros detect overflow
exactly? If the check is done on the actual result and not the operands
then it's not a good overflow check. Additionally, why wouldn't overflow
checks be needed on 32-bit architecture, or any other architecture for that
matter? Integers can overflow there too.

On Fri, Aug 21, 2015 at 4:41 AM, Anatol Belski 
wrote:

> Hi,
>
> Resending this as missed internals at the start.
>
> I was lately rethinking some part of the 64-bit RFC, and also seeing now
> Jakub's work on catching overflows in ext/openssl and Matt Williams
> suggestions on it (which was going a bit more global over it). So I came up
> with these macros with two goals
>
> - standardize the overflow checks
> - do actualy checks only on architectures where it's needed
> - simplify the checks where external libs (openssl, libxml, etc.) use firm
> datatypes like int
>
> #if SIZEOF_INT == SIZEOF_ZEND_LONG
> # define ZEND_LONG_INT_OVFL(zl) (0)
> # define ZEND_LONG_INT_UDFL(zl) (0)
> #else
> # define ZEND_LONG_INT_OVFL(zlong) ((zlong) > (zend_long)INT_MAX) # define
> ZEND_LONG_INT_UDFL(zlong) ((zlong) < (zend_long)INT_MIN) #endif
>
> #define ZEND_SIZE_T_INT_OVFL(size) ((size) > (size_t)INT_MAX)
>
> So having it like
>
> If (ZEND_LONG_INT_OVFL(x)) {
> return;
> }
>
> Compiler would eliminate the branch automatically on 32-bit and ILP64.
>
> Some other macros to do signed/unsigned comparison, these can be extended.
>
> #define ZEND_SIZE_T_GT_ZEND_LONG(size, zlong) ((zlong) < 0 || (size) >
> (size_t)(zlong)) #define ZEND_SIZE_T_GTE_ZEND_LONG(size, zlong) ((zlong) <
> 0
> || (size) >= (size_t)(zlong)) #define ZEND_SIZE_T_LT_ZEND_LONG(size, zlong)
> ((zlong) >= 0 && (size) < (size_t)(zlong)) #define
> ZEND_SIZE_T_LTE_ZEND_LONG(size, zlong) ((zlong) >= 0 && (size) <=
> (size_t)(zlong))
>
> IMHO these and maybe more are missing after the 64-bit RFC. Do you think
> they would make sense? Or would make sense now, or later in master?
>
> Thanks
>
> Anatol
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Fwd: please stop the spam on php-webmaster

[Sherif Ramadan]

A good learning opportunity for "You shouldn't rewrite history because the
consequences can be dire!" ;-)

Also, you want php-webmaster for internal infrastructure, not php-dev, but
I understand you may have felt our message wouldn't get through with all
the flood of emails spawned by that forced push.

On Sat, Aug 8, 2015 at 3:46 PM, Paul Dragoonis  wrote:

> I need someone to turn off the php-webmaster mailer, like now.
>
> I tried to change author info on commits i've made - which worked fine -
> but then blew up the mailer.
>
> I tested this on other github repositories and was like a transparent
> change, all is fine, unless clearly there's a mailer connected to your repo
> and it goes nuts.
>
> Can someone please help!, I'm literally sitting here watching all the
> emails rolling in and can't do anything about it :-(
>
> Many thanks,
> Paul
>

[PHP-DEV] Re: [PHP-WEBMASTER] PHP Manual

[Sherif Ramadan]

On Mon, Jul 20, 2015 at 6:22 PM, Elmer Beardshall 
wrote:

> Thanks for answering.
>
>
>
> Are you satisfied that http://php.net/about.prototypes is a good
> explanation of a typical entry?
>

All patches are welcome https://edit.php.net there is a link on every page
in the manual if you feel it could use some improvement.


>
>
>
>
> ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
>
>Elmer Beardshall   Bland, Virginia
>
> ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
>
> "The learned man aims for more. But the wise man decreases. And then
> decreases again."
>
>
>
>
>
> *From:* Sherif Ramadan [mailto:theanomaly...@gmail.com]
> *Sent:* Monday, July 20, 2015 5:43 PM
> *To:* Elmer Beardshall
> *Cc:* php-webmas...@lists.php.net
> *Subject:* Re: [PHP-WEBMASTER] PHP Manual
>
>
>
> That would be located in the Appendix section of the manual...
>
>
>
> Please see http://php.net/about.prototypes
>
>
>
> >  The third optional parameter is named strict. All optional parameters
> are seen in [ brackets ].
>
>
>
> On Mon, Jul 20, 2015 at 5:39 PM, Elmer Beardshall <
> aebeardsh...@comcast.net> wrote:
>
> Many thanks for making this manual available on line. But where is the
> key to the nomenclature? Colors blue green and purple,  ( vs. [ ?  Is
> there an example or explanation somewhere?
>
>
>
>
>
> bool setcookie ( string $name [, string $value [, int $expire = 0 [,
> string $path [, string $domain [, bool $secure = false [, bool $httponly
> = false ]] )
>
> setcookie() defines a cookie to be sent along with the rest of the HTTP
>
>
>
> ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
>
>Elmer Beardshall   Bland, Virginia
>
> ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
>
> "The learned man aims for more. But the wise man decreases. And then
> decreases again."
>
>
>
>
>
>

Re: [PHP-DEV] Re: Revert unapproved language change, was: Fix division by zero to throw exception (round 2)

[Sherif Ramadan]

On Sun, Jul 5, 2015 at 4:39 PM, Levi Morrison  wrote:

>
>
> I just want to chime in and say that I have a contributed to a popular
> application written in C that actually uses division by zero in a
> useful manner. I feel like the rest of you think this is solely a
> programmer error, and wanted to chime in to reiterate that this is not
> the case. I would be in favor of removal of the error/warning and
> *especially* would be against an exception for division by zero.
> Division by zero as defined by IEEE 754 is actually useful which is
> why it is often followed instead of sticking to a strict mathematical
> definition where it is an error.
>
> I understand that some people are just upset about the
> timing/discussion, which is possibly understandable - I have been too
> busy lately to follow anything so I don't know. I just wanted to jump
> in here and clarify the usefulness of what was actually changed.
>

IEEE 754 is useful, I agree. The warning is also useful, because it helps
the programmer find their mistake more easily. It gives you a file name and
line number to look for. We have to remember that PHP is being used by a
wide array of people with varying skillsets and expertise. Not all of them
know what IEEE 754 is or even how to prevent division by zero. When they
don't debugging the code that results in a division by zero means having to
learn those things first. We're lowering the bar by just handing them the
useful debug information. So removing the warning makes no sense. Having a
warning in your error log screams at you that you potentially have a bug
here and PHP shines a light on it for you so that you can  either fix it or
refactor the code to not result in this potentially buggy behavior.

I don't think the point of this discussion was to discuss which is more
useful, the warning or the error/exception. My immediate concern for
raising this issue, initially, was that we suddenly ended up in a place
where we had neither a warning nor an error, thereby leaving the user with
no useful debug information whatsoever. No indication that there is
potentially buggy code. That's bad. That should not have happened.

[PHP-DEV] Re: Revert unapproved language change, was: Fix division by zero to throw exception (round 2)

[Sherif Ramadan]

On Sun, Jul 5, 2015 at 6:29 AM, Dan Ackroyd  wrote:

> On 4 July 2015 at 20:56, Sherif Ramadan  wrote:
> >
> > I'm proposing that we reconsider removing the warning from floating point
> > division and here's why.
>
> Wait what? I don't remember an RFC about the behaviour changing.
> Did someone ninja commit a change to the language?
>
> Well it sure looks like it:
>
> https://github.com/php/php-src/commit/f9724b93f6592d2f77fa9165038a0ba0db3da0c6
>
> This is absolutely a change that needs an RFC. As the change was done
> without one, please can it be reverted until an RFC is done?
>

I actually fully agree to the IEEE 754 compliance part and I doubt anyone
will disagree on that part as it only stands to benefit everyone. However,
I completely disagree with removing the warning blind-sidedly and
especially two days before the beta1 release like that. I do opt that it be
reverted, however, until the matter is fully resolved. If that happens to
take a day or a month it shouldn't result in releasing ad hoc changes that
will be wish-washy between releases like that should something change. At
the very least let's cherry pick it out of the beta 1 release to ensure
we've fully resolved the matter.


>
> Bob Weinand wrote:
> > I’m just saying that warning in the worst we can have.
>
> You are wrong; it allows:
>
> * People who want it to be an exception to convert it to an exception
> in their error handler.
> * People who want to ignore it can suppress it with the squelch operator.
> * People who want to handle it on a case by case basis in their code can
> do.
>
> This is another case where you are ignoring other people's use-cases,
> and imagining that your use-case is the only valid use-case.
>
> But the technical discussion is one that we should have when someone
> is proposing this change - not when someone has committed it first and
> then is asking for approval.
>




>
> cheers
> Dan
>

Re: [PHP-DEV] Fix division by zero to throw exception (round 2)

[Sherif Ramadan]

Hey guys,

I'm proposing that we reconsider removing the warning from floating point
division and here's why.

While IEEE 754 defines special values for floating point arithmetic when
division by zero occurs, there's nothing stopping the language from
providing useful error information to the user, which may help them debug
potentially buggy code. It's true that it's not exceptional since there is
now well defined behavior in the case of changing division by zero to IEEE
754 standard in PHP. However, PHP didn't actually distinguish between
integer division and floating point division prior to intdiv. So in the
case of division by zero the warning was useful to help someone catch their
mistake.

Now, the onus is on the person writing the code to decipher whether or not
they created a potential division by zero scenario by deducing how they
arrived at INF at some point in their code. This is creating an unnecessary
burden when we've always provided the user with the useful error
information in the past. I'm not sure why we should remove it now, but
based on this conversation I can see that the confusion resonates around
this urge to convert the warning to an exception and the conflict of it not
being exceptional (in the case of floating point math) since there is now
well defined behavior.

So my conclusion is that...

Yes, it's not exceptional. No, we shouldn't throw an exception for division
by zero in floating point arithmetic. No, we shouldn't remove the warning
since it still provides useful information to the person debugging the
code. Debugging the code without this warning can be a monstrosity since
you won't necessarily know at which point in a compounded operation the
division by zero occurred. For example, PHP_INT_MAX ** PHP_INT_MAX creates
an overflow resulting in INF. Though 0 / INF results in 0. So an operation
like (1 / ($x / PHP_INT_MAX ** PHP_INT_MAX) where $x happened to be 0 in
one particular case, makes both hunting down and reproducing the bug quite
difficult without some direction. The warning has historically provided
this direction in the past and I believe that removing it now will only
further the confusion.

I don't think people actually care about whether or not we keep the
warning. I think what they would care about more is the consistency of the
return value and defined behavior, which I believe we have already
addressed very well.

On Thu, Jul 2, 2015 at 4:44 AM, Jakub Kubíček  wrote:

> +1 for everything proposed here :-)
>
>
> Kubo2
>
>
> 2015-07-02 9:59 GMT+02:00 Dmitry Stogov :
> > On Thu, Jul 2, 2015 at 3:26 AM, Bob Weinand  wrote:
> >
> >> > Am 29.06.2015 um 19:14 schrieb Andrea Faulds :
> >> >
> >> > Hi again,
> >> >
> >> >> On 29 Jun 2015, at 18:02, Bob Weinand  wrote:
> >> >>
> >> >> Yes, it generally makes sense...
> >> >> Then I have other questions:
> >> >>
> >> >> - Why do we then still have a Warning? Either we have well-defined
> >> behavior, or we throw an exception. Well-defined behavior *plus* a
> warning
> >> is IMO non-sense.
> >> >
> >> > That’s weird, yeah. We don’t throw warnings for the math functions
> when
> >> you give them odd inputs, e.g. sin(INF) is just NAN, no warning.
> >> >
> >> > I think removing it would make sense.
> >> >
> >> >> - Is it intentional for intdiv and % to throw an Exception instead of
> >> Error or some more specific DivisionByZeroError or similar? (yes, I
> know,
> >> Error is only very recent, but the question still needs to be asked).
> >> >
> >> > Hmm. Using Error might make some sense given it used to raise
> E_WARNING.
> >> I think DivisionByZeroError sounds like a good idea.
> >>
> >> Hey,
> >>
> >> I just committed that to master…
> >>
> >> But I noticed that intdiv(PHP_INT_MIN, -1) isn't very well suited for a
> >> DivisionByZeroError.
> >>
> >> What do you think about adding an ArithmeticError for that case (and
> >> making DivisionByZeroError subclass of it)?
> >> That ArithmeticError could then be reused for negative bitshifts, which
> >> would solve the question what to do with that too.
> >>
> >
> > I think we should introduce ArithmeticError, as you propose.
> >
> > Thanks. Dmitry.
> >
> >
> >>
> >> Thanks,
> >> Bob
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] VCS Account Request: trowski

[Sherif Ramadan]

+1 from google...@php.net

On Tue, Jun 30, 2015 at 1:42 AM, Aaron Piotrowski  wrote:

> Quickly applying bug fixes.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Nov 7, 2014 at 4:49 PM, Stas Malyshev 
wrote:

> Hi!
>
>
> So the question here is how common is the case of PUT+mulitpart/form-data?
>


Well, that's what I'm trying to establish. Based on the information I have
available, there have been a few dated bug reports asking for this. There
are also a lot of forums questions found on github/stackoverflow/etc...
that apparently find this useful. How useful it is and how common the use
case is may not be enough, though. Based on your feedback I can definitely
see a lot of people making future feature requests to add support for
additional content-types and I really don't think the SAPI implementation
should necessarily start heading down that road. Only because based on this
discussion I fear that no one other than myself will be eager to support
it. I'd rather not introduce cruft into PHP if I can avoid it.

I'll gather some more data and perhaps see if an initial implementation can
prove extensible enough.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Nov 7, 2014 at 12:47 AM, Will Fitch  wrote:

>
> On Nov 7, 2014, at 12:38 AM, Sherif Ramadan 
> wrote:
>
>
>
> On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch  wrote:
>
>>
>> Sherif - I’m just going to be straight here. I haven’t seen support for
>> your proposal at all in this thread.  You continue to try and make this
>> case, but it continues to be shot down with absolutely valid issues, and
>> your only responsive action is to argue back.  Why aren’t you considering
>> alternatives?  Everything - and I do mean everything - that you want is
>> available in pecl/http, and there’s already an RFC to get it into core.
>> Why can’t you get behind that and either support it, or move to propose an
>> alternative that is supportable by at least someone.  Your current proposal
>> is not supported by anyone in this thread, and you still can’t see that.
>>
>> I admire and appreciate your efforts in making PHP better, but it’s time
>> to go back to the drawing board on this proposal.  Everyone is against it,
>> and I feel this thread’s patience is running thin.
>>
>
>
> I think you're looking too closely at the problem to have an objective
> view. While I appreciate your continued input and feedback, I don't believe
> you're fairly judging my motives or my objectives. Who says I'm not
> considering alternatives? You have to keep in mind the RFC is still in
> draft. I'm technically not even putting up for discussion yet because I've
> failed to make a coherent proposal. I get that. I'd still like to hear what
> others have to say. I will make my own assessments of the collective facts.
> In the mean time I'm OK with the discussion of my initial proposal being
> objectionable. I gladly embrace failure as I expect to learn from it.
>
>
> It’s only a failure if you don’t learn from it and stop. I admire your
> efforts.
>
>
> I'm not sure why it is you feel as though me having a technical discussion
> with the community equates to me agreeing with everyone else's opinion or
> ending a discussion on the note that it is no longer useful because
> everyone disagrees with me.
>
>
> The discussion would be more useful if you proposed an alternative.  So
> far, all I’ve seen is arguments why your original discussion could work.
>
>
> I gather valuable knowledge from disagreement and intend to pursue those
> disagreements until I can reach a fully objective outlook on all of the
> moving parts at hand. I don't wish to abandon this discussion because the
> initial proposal has no support.
>
>
> Nor should you. I do feel that time has been reached as there are multiple
> people that have retired from discussing this further. That is an indicator
> that this discussion has run its course.
>
>
> I'm sorry if you feel that you are no longer interested in the discussion,
> but can you at least refrain from cluttering the discussion aggressively
> with your synopsis? Everyone is providing valuable objective outlooks and
> those that have no more objectivity have seemingly refrained from further
> discussion. That I'm perfectly OK with. What I'm not OK with is someone
> that feels they must terminate the discussion because there is
> disagreement. I am in the very process of understanding others'
> disagreements. Please do not impede on my efforts by assuming you have any
> idea what is going on in my head.
>
>
> I am very interested in discussing this - but not in discussing the same
> proposal over and over.  We have beaten a dead horse, and the horse has
> come back as a zombie and been defeated twice over.  I actually believe
> your point is valid that the HTTP interface could use some work, but the
> approach you’re pushing just isn’t it.
>
>
> Thanks.
>
>
>

Will, once again, you continue to make unfounded assumptions about me and
about the discussion. I get that you don't like what I'm saying. I just
feel that you've stated it enough times now :)

Remember, email doesn't disappear. People can always scroll back up and
reread what you've already said.

Thanks again for your reiterated input. I'd like to continue reading what
others are adding to the discussion like Stas, which had not voiced in
opinion prior to your little interjection.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch  wrote:

>
> Sherif - I’m just going to be straight here. I haven’t seen support for
> your proposal at all in this thread.  You continue to try and make this
> case, but it continues to be shot down with absolutely valid issues, and
> your only responsive action is to argue back.  Why aren’t you considering
> alternatives?  Everything - and I do mean everything - that you want is
> available in pecl/http, and there’s already an RFC to get it into core.
> Why can’t you get behind that and either support it, or move to propose an
> alternative that is supportable by at least someone.  Your current proposal
> is not supported by anyone in this thread, and you still can’t see that.
>
> I admire and appreciate your efforts in making PHP better, but it’s time
> to go back to the drawing board on this proposal.  Everyone is against it,
> and I feel this thread’s patience is running thin.
>


I think you're looking too closely at the problem to have an objective
view. While I appreciate your continued input and feedback, I don't believe
you're fairly judging my motives or my objectives. Who says I'm not
considering alternatives? You have to keep in mind the RFC is still in
draft. I'm technically not even putting up for discussion yet because I've
failed to make a coherent proposal. I get that. I'd still like to hear what
others have to say. I will make my own assessments of the collective facts.
In the mean time I'm OK with the discussion of my initial proposal being
objectionable. I gladly embrace failure as I expect to learn from it.

I'm not sure why it is you feel as though me having a technical discussion
with the community equates to me agreeing with everyone else's opinion or
ending a discussion on the note that it is no longer useful because
everyone disagrees with me.

I gather valuable knowledge from disagreement and intend to pursue those
disagreements until I can reach a fully objective outlook on all of the
moving parts at hand. I don't wish to abandon this discussion because the
initial proposal has no support.

I'm sorry if you feel that you are no longer interested in the discussion,
but can you at least refrain from cluttering the discussion aggressively
with your synopsis? Everyone is providing valuable objective outlooks and
those that have no more objectivity have seemingly refrained from further
discussion. That I'm perfectly OK with. What I'm not OK with is someone
that feels they must terminate the discussion because there is
disagreement. I am in the very process of understanding others'
disagreements. Please do not impede on my efforts by assuming you have any
idea what is going on in my head.

Thanks.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds  wrote:

>
> > On 7 Nov 2014, at 00:53, Stas Malyshev  wrote:
> >
> > Hi!
> >
> >> Again, I think you're oversimplifying the problem. For one, you don't
> know
> >> that the payload is JSON unless you check the Content-type header
> yourself,
> >> and you really shouldn't have to since PHP could easily do this for you.
> >
> > Sure, PHP could easily do this, or any other one specific use case for
> > you. What it can't do, however, is to do all 1000 use cases that modern
> > REST application presents, automatically for you. What if you use XML
> > and not JSON? What if you use both and determine which one it is by
> > request URL suffix being .xml or .json? What if it instead is switched
> > by query parameter? What if also it can be compressed, encrypted and
> > wrapped in some MIME multipart message? Having all these complications
> > handled in the core of PHP would be extremely hard, not because each of
> > them is hard, but because there can be so many of them. And you'd run a
> > big change of PHP still not matching your specific case exactly, or
> > being behind times, because core can not evolve as quickly as userland
> > does. That's why it's better done in extensions or user space - unless
> > you can identify a case which covers a huge proportion of all cases -
> > just like forms are for POST. For generic REST, I'm not sure there's
> > such case, except for very generic API giving access to the basic
> > request, its fields and supporting basic URL/MIME parsing.
>
> Even just parsing JSON isn’t as simple as it sounds. There are several
> things users might like to configure, several ways to parse JSON (objects
> vs. arrays, big numbers as floats or strings, etc.), while for form-data
> there’s only one way.
>

Well, in this case it will be parsed as an array since $_POST is naturally
parsed as an array. Also, since $_POST/$_GET are typically always processed
as strings it would only make sense to use big numbers as strings in the
JSON parsing as well. I don't think this is the big issue. The bigger issue
is do users typically find the population of $_POST more useful than just
reading the input stream themselves and handling the JSON payload on their
own.


>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Nov 6, 2014 at 7:53 PM, Stas Malyshev 
wrote:

> Hi!
>
> > Again, I think you're oversimplifying the problem. For one, you don't
> know
> > that the payload is JSON unless you check the Content-type header
> yourself,
> > and you really shouldn't have to since PHP could easily do this for you.
>
> Sure, PHP could easily do this, or any other one specific use case for
> you. What it can't do, however, is to do all 1000 use cases that modern
> REST application presents, automatically for you. What if you use XML
> and not JSON? What if you use both and determine which one it is by
> request URL suffix being .xml or .json? What if it instead is switched
> by query parameter? What if also it can be compressed, encrypted and
> wrapped in some MIME multipart message? Having all these complications
> handled in the core of PHP would be extremely hard, not because each of
> them is hard, but because there can be so many of them. And you'd run a
> big change of PHP still not matching your specific case exactly, or
> being behind times, because core can not evolve as quickly as userland
> does. That's why it's better done in extensions or user space - unless
> you can identify a case which covers a huge proportion of all cases -
> just like forms are for POST. For generic REST, I'm not sure there's
> such case, except for very generic API giving access to the basic
> request, its fields and supporting basic URL/MIME parsing.
>


Sure, you make a good point, here. The handling of a RESTful request in
user land may vary based on individual requirements. However, I'm not
proposing that PHP does the actual handling of the request, just that it
makes user land code more readily equipped to enable the user to do that
handling. In the same way that it does for POST. This creates some more
consistency and makes the typical request slightly more ubiquitous since
users are already used to $_POST and $_FILES when handling incoming request
input.

For this to be possible in a more generic sense this would mean that PHP
only relies on the Content-encoding and Content-type headers to determine
how to decode the payload and parse its contents into super global
variables such as $_POST and $_FILES. This is currently what PHP's SAPI
implementation already does. The changes required to make this available to
a wider array of use cases such as JSON vs form-url-encoded encoding, for
example, are not so complicated. After that it's up to the user to decide
what to do with the data in terms of handling the request.

Content-encoding will most likely be handled at a higher level than PHP as
it is in most cases today (deflate, etc... handled by the webserver)

If the Content-type is applicatoin/json, for example, instead of the normal
application/x-www-form-urlencoded, PHP would simply parse the enclosed
entity body as JSON rather than urldecode it. If the Content-type header is
set  to a multipart/form-data MIME, then PHP does what it typically does
with POST, but allows PUT to work the same. You would still stick to the
same boundary requirements of the multipart/form-data MIME in the same way
that post does, so encoding can't vary. If the Content-type header is
application/binary, for example, we can simply make the file available in
$_FILES or just leave it in the input stream (probably best to just leave
it in that case). If PHP fails to find these headers properly set it would
fall back to the same thing it does today (leave it up to the input stream
consumer to parse the entity body).

I suppose if we also exposed the request headers to the user we could make
it more effective for them to make their own decisions about handling other
edge cases differently based on those request headers (such as in the case
of non-standard headers X-*, for example).

Here, I'm just proposing that PHP take on the addition of PUT handling in a
similar fashion that it does for POST, but only in the even that the
request comes in as a mulitpart/form-data MIME type. This could make a lot
of people's lives a little easier in dealing with PUT, but it's clearly not
a solution to for abstracting away the entire logic of handling RESTful
requests.

So I can definitely see your hesitation to include this in core.



>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
>

[PHP-DEV] Re: New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Nov 6, 2014 at 6:42 AM, Sanford Whiteman 
wrote:

> Prove I "believe a multipart/form-data mime cannot be sent along with a
> PUT request" using messages I have sent to this list.  You are basically
> lying for effect at this point. I never said that, took pains to explain
> that I am not saying that, gave examples utterly to the contrary... yet you
> make stuff up anyway.



I'm done with this. I hope you find a more honest way to defend your
> proposals in the future.

-- S.


I'm honestly not sure what it is you are saying anymore. All I know is that
so far you're opposed to populating a super global like $_POST or $_FILES
with data from a multipart request that uses the PUT verb rather than POST,
based on this statement you made early on in the thread:



> If you're PUTing such POSTful content-types for any reason other than
> storing the entire resource, you're doing HTTP wrong.



Here, you are clearly implying that the content-type is somehow associated
with POST and not PUT and that one should never attempt to do anything
other than store the entirety of the enclosed entity upon receiving a PUT
request. Otherwise we're violating the HTTP specification. This can be
clearly inferred from these words.

The intent is to store the entity, yes, but what is so bad about allowing
people to process information from that entity before hand? Certainly that
is the entire point of PHP, no? You receive some HTTP request through PHP
so that you can somehow do some pre-processing on it before serving up the
response. Otherwise you'd just have your webserver deal with it if it was
considered a static asset.

I certainly have no ill intentions. I'm neither a liar nor have I brought
your ethics into question during this discussion. I assume that people have
the best of intentions until they prove otherwise. So I would greatly
appreciate it if you refrained from doing so yourself and began to assume
that we all have the best of intentions here.

If your argument isn't that one should NOT send multipart/form-data
content-type along with a PUT request, or that PHP should not attempt to
populate the parts of the request in super globals, than what is it? Please
help me to understand your opposition to this proposal so that we can reach
some consensus about its validity.

Certainly we can either learn to be civilized in our technical discussion
or we can refrain from participating in it. Making this person isn't going
to benefit the PHP community in any way.

Lastly, I would like to say that I sincerely appreciate your time and
contributions to this discussion and I consider them valuable regardless of
whether or not I fully agree with you, personally. I only wish to come away
from this discussion with what is in the best interest of the community at
large and not my own individual interests. I hope that's clear and
alleviates any misconceptions of my intent to aspire for personal gain.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Nov 6, 2014 at 4:56 AM, Sanford Whiteman 
wrote:

> > PUT is not intended to necessarily store the request entity body on the
> file
> > system. Its intention is to store the entity body at the request URI.
>
> I never said it was.  I used the expression "store at the URI" about
> 10 ten times on this topic.  You are arguing in bad faith by putting
> words in my mouth.  Stop.
>

Well, let's not exaggerate. You used the term "store at the request-URI"
once in the message from which that reply was intended. However, I was
responding to: "What you will get is the entire multipart stored within the
filesystem at the mapped URI."

Which isn't necessarily true. Albeit the phrasing here can be ambiguous and
open to interpretation, because I read it as "the URI maps to the
filesystem". The object of the sentence is pretty ambiguous here, but in
any case the filesystem itself really has nothing to do with where the data
will be stored. It could be stored in a database, or directly on the node
accepting the request, or even distributed remotely to other nodes. That
part is an implementation detail left up to the server. The point is that
the URI signifies the place where the client intends to make the resource
available. So the client should be able to retrieve said resource from that
URI (or such is the intent).


>
> In a barebones implementation with just an HTTPd, PUT does mean the
> filesystem, which gives an easy example of how incredibly semantically
> different it is from POST. Most people do not understand the concept
> unless you give them a simple example.
>

Again, you're getting into implementation details here and deviating away
from the specification. There are httpd implementations where PUT does not
correlate URI to file system path. I do fully understand the intent of PUT.
I can also do without snarky remarks like this where you feel you need to
dumb things down as though I have no clue what I"m talking about (like with
the LMGTF urls and this feeble attempt at explaining PUT vs. actually
focusing on the discussion).

I do have some understand of how the web works. I am responsible for
working out problems on the web for one of the world's largest sites, after
all. So give me some credit.

To tackle your point fully, however, you want to keep in mind that you are
reading too much into the specification. The spec is laying out the intent
of PUT in that the client should be allowed to determine the designated URI
where the entity will be stored. This doesn't restrict the media type of
the entity in any way. You're assuming that the enclosed entity and the way
in which it is stored are disconnected. This is not necessarily true nor is
it a part of the specification.

Here we just want to ensure two things...

1) That the request URI is the place where client will store the entity
2) That the server cannot decide to change this URI without the approval of
the client

We can fully meet all of these requirements even if the enclosed entity is
infact a multipart mime. There should also be no restriction on the server
or end-point decomposing this request in order to better figure out how it
should be stored. Just like your email server can inspect headers and
decompose the mime to inspect the email for spam/viruses/etc... before
figuring out where it should go. It doesn't mean we've broken anything.
Just that we've made it easier for PHP users to handle these requests more
consistently. For example, perhaps I need check for authentication data, or
there are multiple files enclosed in the request (file versioning, for
example which is possible in Amazon S3 today). These are important factors
you don't seem to be taking into consideration at all. In fact the more you
try to dumb down the specification, the less you are sticking to its
requirements, because the spec is actually very straight forward and
simple. It's describing the client's intent from the request. That's it.
Nothing less, and nothing more. We aren't violating that intent if we allow
multipart form data to be populated in PHP by this request.




>
> > So this unfounded claim that decomposition should not happen within PHP
> at the request level, isn't a justification for prohibiting PHP from
> decomposing the body.
>
> I made no such claim.  I maintain that decomposition not be *required
> to happen* within PHP.  I couldn't care less if you make it optional
> and don't use the $_POST superglobal. I've said this over and over.
> Expose the core MIME parser to the user.  That'll make it easily used
> by frameworks, or via auto_prepend_file.  Do not do it automatically
> for all requests.
>
>
We are exposing the benefits to the user by populating the super global.
Letting userland do the work would make for a less efficient
implementation. I'm not seeing any objective reason why we shouldn't do it
automatically. Just that you're suggesting we don't. Is there a reason why
not?


> > For example, if the Content-type designated in the requ

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Nov 6, 2014 at 4:32 AM, Sanford Whiteman 
wrote:

>
>
> > First of all, RFC 1867 is not a standard. It's an experimental protocol
> > definition.
>
> Oh nonsense.  You know very well that RFC 1867 conformance is an
> industry standard for file uploading  When 2388 says "originally set
> out in [RFC1867] and subsequently incorporated into [HTML40]" it is
> not treating 1867 as some fringe document. Non-HTML uploaders
> (Flash/Java/Silverlight/cURL/all of them) use RFC 1867 as their design
> spec, not as some wacky experiment.
> http://lmgtfy.com/?q=rfc+1867+file+upload+support


I know that RFC 1867 clearly states it is not a standard.

"This memo defines an Experimental Protocol for the Internet community.
This memo does not specify an Internet standard of any kind." [1]

Also, you seem to be quoting out of context with the intention that the
reader will not try to seek out said context and simply assume your
supporting argument is sound and well-rounded. It is not. The standard you
are referring to [RFC 2388] only mentions the non-standard [RFC 1867] in
its introduction to state where the definition of multipart form data was
derived in these applications. This does not constitute RFC 1867 as a
standard.

Yes, HTML form data is where the need for multipart form data was
originally derived. As we know, client UAs implementing forms typically
either restrict the method to either GET, or in the case of constructing
multipart/form-data MIME, POST. However, as you mentioned, it has since
spread to be implemented in many other applications (outside of the scope
of HTML) such as in the case of FDFs.

I understand all of this and I get why you're making a strong connection
between POST and multipart/form-data mime. The part I'm not getting is why
you believe a multipart/form-data mime cannot be sent along with a PUT
request. The two things are independent of one another as I see it. One is
a media type header and describes the enclosed entity type (i.e.
multipart/form-data or application/x-json or whatever the content type may
be) and the other is an intent of request verb that describes the user's
intention in making the request (i.e. POST/PUT).


[1] https://www.ietf.org/rfc/rfc2388.txt

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Nov 6, 2014 at 3:20 AM, Sanford Whiteman 
wrote:

> > Nowhere did I suggest that the request verbs themselves (i.e. PUT and
> POST) have the same intent. Just
> > that the handling of multipart-form data is not specific to either one of
> > those verbs.
>
> Define "handling." :/
>

Specifically, parsing the form data and populating it somewhere accessible
to the user as it is today in $_POST and making any binary upload available
in $_FILES or some other fashion. Ideally, making handling PUT more
consistent with the way PHP handles POST.


>
> "Handling" as in "interpreting multipart/form-data as key-value
> pairs": a specific, intimate relationship with POST exists in RFC 1867
>

First of all, RFC 1867 is not a standard. It's an experimental protocol
definition. No where in the internet standards tracking documents do I see
a definition that restricts multipart/form-data to POST. I think what
you're referring to is the fact that the client UAs typically only ever
handle form data as multipart/form-data mime as POST-specific requests.
This is of course tied to the fact that client UAs don't typically follow
the same intents of a RESTful API client/server relationship. Allow me to
re-iterate the fact that this is one of the primary focuses of this
discussion. That people normally want to deal with PUT requests in PHP
under the umbrella of building their own RESTful APIs.


>
> > I see no reason why this would be a negative impact on PHP.
>
> Because if someone PUTs 2 GB of multipart/form-data I don't want it
> decoded just because somewhere in my code path there's a reference to
> $_POST.
>
>
It's the same thing as with a POST request today in PHP. Nothing is
stopping anyone from sending a you 2 GB multipart/form-data POST request
either. You should be checking intent before dealing with $_POST from the
$_SERVER['REQUEST_METHOD'] anyway, since you can't realy on $_POST
necessarily being indicative of the request method anyway.


> -- S.
>

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Nov 6, 2014 at 2:44 AM, Sanford Whiteman 
wrote:

> > The HTTP specification doesn't restrict how the request body is encoded
> > based on the request verb.
>
> I never said it did... please don't put words in my mouth.
>
> As Will notes, you're sidestepping the point, which standards-savvy
> people have been driving at for years: the semantic differences (==
> intent, == meaning) among HTTP methods. HTTP specifications *do*
> define -- in your words, "restrict" -- the intended disposition of the
> entity-body based on the HTTP method.  The methods *do* distinguish
> whether the entity-body is intended as a precomposed resource to be
> stored at the request-URI (PUT) -- or whether it may contain key-value
> strings, multipart MIME data, or arbitrary text and/or binary data
> ranges (POST) which must be interpreted by application code at the
> request-URI (which must itself exist) as they have no inherent final
> disposition.
>
> It's easy to certify the semantics in your lab.
>
> Set up a capable web server with no preprocessor at all (no PHP, no
> SSI, nothing).  Choose a URI that currently returns a 404, like
> /test.abc. PUT a well-formed multipart/form-data body to that URI.
> What you will get is the entire multipart stored within the filesystem
> at the mapped URI.  And provided the server's file extension <-> MIME
> mappings are consistent, you'll then be able to GET the file as
> multipart/form-data.
>
> Now POST that body to another nonexistent URI.  You'll get a 404 or
> 405. Full stop.
>
> This core difference is really not that hard to understand, and
> there's no reason for PHP to act, stupidly, like it it isn't there (as
> in make-people-dumber stupid, not make-life-easy stupid).
>

First off, let's make some discrepancies abundantly clear.

PUT is not intended to necessarily store the request entity body on the
file system. Its intention is to store the entity body at the request URI.
That is to say, the URI !== File System.

So this unfounded claim that decomposition should not happen within PHP at
the request level, isn't a justification for prohibiting PHP from
decomposing the body. For example, if the Content-type designated in the
request indicates application/binary it is safe to say that PHP should not
attempt to disassemble the input stream beyond applying the decoding from
the Content-encoding header (which may actually happen at the web server
level). However, in this event it would make it a lot more convenient for
the client if the entity is stored in $_FILES where its access is still
more manageable through the receiving code. Wherein one can take advantage
of reliable features such as move_uploaded_file(), which inhibit some
security measures that would be beneficial to the user. Again, we haven't
changed the intent of the request by making it easier for the user to take
advantage of existing PHP features to service said request. We also haven't
we changed the typical outcome of this request, because through today's
work-flow the input stream remains at the discretion of the user. With the
change of storing the input stream in $_FILES, the temporary file gets
discarded by PHP if the user doesn't move it. Same thing if they don't do
anything with the input stream (today).

Additionally, I don't believe that this makes PHP or its users any
"dumber". It just makes handling the request in PHP more consistent and
intuitive. This has both added convenience as well as added performance and
security benefits by taking advantage of already existing functionality in
PHP.

I completely understand, however, that the existing functionality only
targets form data. So while PUT requests aren't form data, they are still
very much a part of the overall handling of requests that can be sent to
PHP. So why not expand the same functionality to also target those use
cases? While you may see this as a fundamental change in the way PHP works,
it's not actually too far off from what PHP had always intended (which was
dealing with the web in the first place). It just so happens that PHP's
primary intention has been outgrown by the evolution of the web, which now
entails more RESTful APIs than before.



>
> > multipart form data is useful for including both form data and binary
> data with successive parts
>
> Of course.  Multipart MIME is also key to the modern e-mail ecosystem.
> And, similarly, multipart e-mails are kept as opaque as possible in
> transit. Antivirus and spam scanners need to peek inside multipart
> mail, but they don't decompose them and put the parts back on the wire
> separately, because that is not the meaning of "transfer this e-mail."
> Neither do end-user apps aim to decompose MIME messages when they're
> idling in a message db, because that's not the meaning of "save this
> e-mail."  On the other hand multiparts *are* intended to be decomposed
> by mail apps when a user opens them: in that case, there's a clear
> semantic justification for expanding the contents for t

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Wed, Nov 5, 2014 at 10:53 PM, Will Fitch  wrote:

>
> > On Nov 5, 2014, at 10:00 PM, Sherif Ramadan 
> wrote:
> >
> >
> >
> > On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch  wrote:
> >
> >
> >
> > Easy - you have no idea what the input type is from PUT without checking
> the incoming type.  With POST, you know exactly what it is. PUT input code
> be JSON, multipart mime, a file or a whatever the dev wants.
> >
> >
> > That's not necessarily true. There are many APIs that will send POST
> requests with a JSON payload in the request body. This is specifically why
> PHP won't bother parsing the request entity body unless the content-type
> header is form ulr-encoded. Additionally you have to take
> Content-encoding[1] into consideration as HTTP doesn't require that the
> body of a POST request be url-encoded, just that the client specifies the
> content-encoding and content-type[2][3] for entity decoding and then it
> becomes up to the server how to handle or even accept the entity.
>
> I think a simple quote from RFC 2616 is necessary:
>
> "The fundamental difference between the POST and PUT requests is reflected
> in the different meaning of the Request-URI. The URI in a POST request
> identifies the resource that will handle the enclosed entity. That resource
> might be a data-accepting process, a gateway to some other protocol, or a
> separate entity that accepts annotations. In contrast, the URI in a PUT
> request identifies the entity enclosed with the request -- the user agent
> knows what URI is intended and the server MUST NOT attempt to apply the
> request to some other resource. If the server desires that the request be
> applied to a different URI,
> it MUST send a 301 (Moved Permanently) response; the user agent MAY then
> make its own decision regarding whether or not to redirect the request."
>
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)
>
> There is nothing relevant to data transformation between PUT and POST. It
> is, for all intents and purposes, two completely different methods and you
> should not assume one is similar to the other - especially based solely on
> what you want PUT to do. PUT can contain query strings, POST-like bodies
> and files or a combination of any.
>

Correct, the HTTP request verb is about describing the intent of the
request, which is what I said earlier. It is not about how to treat the
enclosed entity body. For that the specification describes additional
headers such as that of Content-type header. Nowhere did I suggest that the
request verbs themselves (i.e. PUT and POST) have the same intent. Just
that the handling of multipart-form data is not specific to either one of
those verbs.


>
> Bottom line - you’re trying to change PHP’s form handling approach with
> your view of what PUT could/should be doing.  Don’t do that.
>

I'm trying to take advantage of the fact that PHP can parse the multipart
data regardless of the request verb. This is a good thing. It has added
benefits. I see no reason why this would be a negative impact on PHP. If
anything it makes PHP more useful in dealing with additional request types
without the user having to parse the input stream themselves.



>
> It’s blowing my mind that you are still arguing this point, and I believe
> it’s time to put it to bed.  Come up with a better solution, put this RFC
> to a vote (even without a patch) or retract it.  You have have almost
> nothing but criticism, and this thread is at the point of wasting valuable
> time.
>
>
I'm sorry you feel that there is a waste of valuable time in this thread.
By all means, if you feel that this thread is a waste of your time please
disregard it. I have no intention of putting anything to a vote until I
feel it is ready. Since it is currently a draft I feel no obligation to
retract it. I do appreciate your time and input, however.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Wed, Nov 5, 2014 at 10:03 PM, Sanford Whiteman 
wrote:

> For the umpteenth time, *in what situation must you PUT
> multipart/form-data or multipart/x-www-form-urlencoded only to treat it,
> semantically, as a POST*? Which UA cannot send a POST? It's like we're
> completely upside down on this thread.


> If you're PUTing such POSTful content-types for any reason other than
> storing the entire resource, you're doing HTTP wrong.  Truthfully: if
> someone said, "Yeah, so we got into PUT lately, we use it for Ajax form,
> er, posts, for, um, speed or something," would you not be like, "Wat?"
>


The HTTP specification doesn't restrict how the request body is encoded
based on the request verb. That is up to the content-type and
content-encoding headers. The request verbs themselves are indicative of
intent in the request, not necessarily the composition of said request. So
we're dealing with decomposition not intent. That part is up to the user
not PHP.

multipart form data is useful for including both form data and binary data
with successive parts. Typically the method applied for this mime in the
client UA is POST, but many APIs may apply a PUT request using multipart
form. There's no reason to be restrictive of that in PHP if we doesn't
break compatibility, I don't think.

These are real world problems that people deal with in on the web every day.

Here are some sources to demonstrate real world use cases and issues:

- https://github.com/symfony/symfony/issues/9226
- https://www.drupal.org/node/1270190
-
http://uncorkedstudios.com/blog/multipartformdata-file-upload-with-angularjs
- https://bugs.php.net/bug.php?id=55815

Let's face it. The web is a very imperfect place, but it's very tolerance
to fault is what makes it work so well. Clearly we don't agree with
everything that's done on the web, but that doesn't mean we can't help make
PHP a little more useful on the web.




>
> -- S.‎
>

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch  wrote:

>
>
>
> Easy - you have no idea what the input type is from PUT without checking
> the incoming type.  With POST, you know exactly what it is. PUT input code
> be JSON, multipart mime, a file or a whatever the dev wants.
>


That's not necessarily true. There are many APIs that will send POST
requests with a JSON payload in the request body. This is specifically why
PHP won't bother parsing the request entity body unless the content-type
header is form ulr-encoded. Additionally you have to take
Content-encoding[1] into consideration as HTTP doesn't require that the
body of a POST request be url-encoded, just that the client specifies the
content-encoding and content-type[2][3] for entity decoding and then it
becomes up to the server how to handle or even accept the entity.

[1] http://tools.ietf.org/html/rfc2616#section-14.11
[2] http://tools.ietf.org/html/rfc2616#section-14.17
[3] http://tools.ietf.org/html/rfc2616#section-7.2.1


>
> You’re suggesting we change the fundamental approach of PHP in terms of
> what these superglobals represent.



Not at all, $_GET and $_POST in PHP have always represented form data. I
wish to keep that intact. This approach merely amends under which HTTP
verbs form data can be accepted and the potential to accept media types
other than form/url-encoded. If the latter part deviates too much from the
concept of form data (it likely does) then that can become a separate vote
in the RFC.


> I think from the feedback on this list, the approach you’re suggesting is
> far from welcome. Perhaps this is something you should stop arguing and
> start looking at improving your RFC with something that’s different and
> potentially acceptable.
>
>

Improving the RFC is precisely what I'm looking to do :)

Surely the only way to find out what is or is not acceptable is to poll
others get some form of popular consensus. Perhaps you should take the
discussion as less of a battle and more of an opportunity to voice
individual objectivity? I have no intention of being hostile. I'm also more
than open to the possibility that this RFC may not be favored, but that
doesn't negate the effort to build a more favorable RFC based on this
discussion.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds  wrote:

>
> > On 6 Nov 2014, at 01:29, Sherif Ramadan  wrote:
> >
> > So you're actually describing two semi-different problems here. One is
> that PHP doesn't actually inform you of the HTTP request VERB strictly
> through the naming of the super global variables $_POST and $_GET. However,
> $_POST being populated, right now, in PHP, strictly means the request verb
> was POST and that the content-type header received was multipart form data.
> Which means that sending something like a JSON payload (Content-type
> application/x-json or whatever) in the body of a POST request still doesn't
> populate the $_POST super global variable even though the HTTP request VERB
> was indeed POST.
>
> That’s not actually my complaint. The thing is that, until now, you could
> assume what was in $_POST was from a POST request. To allow data from PUT
> and DELETE requests to go there by default is probably not a good idea,
> because POST has quite a different meaning from PUT and DELETE.
>

Sure, $_POST has become synonymous with form data. I get that. I have no
idea why you think populating it with data from other request types,
however, would necessarily be a bad idea. If the request verb changes but
the request contains a multipart mime, I see no reason not to populate it
other than its name becoming more alluding. The meaning of PUT or DELETE is
irrelevant here because all we're discussing is parsing the form data part
of the multipart request (regardless of it's HTTP request VERB). So the
meaning of the request verb isn't a justification for what to name the
super global variable that gets populated either. The super global was
intended for form data and I'm not changing that intention when allowing it
to get populated by additional request verbs.


>
> > The other problem is that the semantics of REST itself are quite
> different from how PHP currently deals with the request data. In that PHP
> only cares about form data. However, this is quite antiquated with todays'
> modern use of HTTP growing in API-specific functionality. For example,
> companies like Twitter and Tumblr, demonstrate a vast majority of their
> traffic currently coming in at the API-level where things are usually
> handled in a RESTful manner. So for the PHP power houses today, PHP doesn't
> quite lend itself well to dealing with these problems first-hand. Instead
> we have to hack our way around them in userland, which can be more
> error-prone and less obvious.
>
> Er… I wouldn’t say that PHP really handles REST APIs badly, or that the
> userland approach is error-prone or less obvious. Using JSON isn’t
> difficult, you just do this:
>
> $data = json_decode(file_get_contents(‘php://input')) or die();
>
> This isn’t a hack. It’s a straightforward and obvious way to do this.
>


Again, I think you're oversimplifying the problem. For one, you don't know
that the payload is JSON unless you check the Content-type header yourself,
and you really shouldn't have to since PHP could easily do this for you.
Further more, you ignore all the other aspects of parsing the request body
like when the PUT payload is a multipart mime, with both form data and a
base64 encoded binary part or several of them. Again, PHP could just as
easily take care of this in the same way it does now with POST and populate
$_FILES and other form data accordingly.



>
> > While that solution solves one specific problem (dealing with multipart
> form data of request types other than POST), it doesn't quite tackle some
> of the broader issues of dealing with incoming HTTP request in PHP that I
> would like to tackle.
>
> Yes, I’m aware it doesn’t. I don’t think that the PUT/DELETE issue really
> justifies your RFC. I don’t think there are any other problems which do,
> either. There are better ways to solve them.
>

Well, the RFC is intended to tackle the current issues of dealing with the
HTTP request where PHP now fails. Everything outside of form data and
multipart requests specifically using POST fall under that umbrella. So I'm
not sure why you think this RFC isn't justified.

What are these better ways? Please, do elaborate. I'm more than open to a
better solution even if that entails heading down a different path. I just
don't think that a response of "this RFC doesn't help because there's
something better", without stating what that is or why this RFC is less
than acceptable is a very constructive response. In that it only aims to
shutter the discussion and turn people away from it rather than help it
evolve into something better.


>
> > I also think you're diminishing scope of this problem and the number of
> people affected by it. You not o

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Wed, Nov 5, 2014 at 7:31 PM, Andrea Faulds  wrote:

>
> > On 5 Nov 2014, at 22:29, Sherif Ramadan  wrote:
> >
> > From all the people I've spoken with that have a problem with handling
> PUT
> > requests in PHP, it seems that they'd rather have PHP populate
> > $_FILES/$_POST automatically in this case. Which would be relatively easy
> > to do by modifying the default post reader function in the SAPI
> > http://lxr.php.net/xref/PHP_5_6/main/php_content_types.c#51 however,
> that
> > is itself a small BC break.
> >
> > Does anyone have any recommendations on what they think the best approach
> > is? I'd appreciate any feedback/suggestions/constructive-criticism.
> Thanks!
>
> I don’t think auto-populating for PUT/DELETE etc. is a good idea, they’re
> quite different semantically. If I send a DELETE request to code expecting
> a POST, and PHP pretends it’s a POST request, that’s bad.
>

So you're actually describing two semi-different problems here. One is that
PHP doesn't actually inform you of the HTTP request VERB strictly through
the naming of the super global variables $_POST and $_GET. However, $_POST
being populated, right now, in PHP, strictly means the request verb was
POST and that the content-type header received was multipart form data.
Which means that sending something like a JSON payload (Content-type
application/x-json or whatever) in the body of a POST request still doesn't
populate the $_POST super global variable even though the HTTP request VERB
was indeed POST.

The other problem is that the semantics of REST itself are quite different
from how PHP currently deals with the request data. In that PHP only cares
about form data. However, this is quite antiquated with todays' modern use
of HTTP growing in API-specific functionality. For example, companies like
Twitter and Tumblr, demonstrate a vast majority of their traffic currently
coming in at the API-level where things are usually handled in a RESTful
manner. So for the PHP power houses today, PHP doesn't quite lend itself
well to dealing with these problems first-hand. Instead we have to hack our
way around them in userland, which can be more error-prone and less obvious.


>
> However, I think the solution is simple: Add a function to do
> multipart/form-data parsing. Not a suite of functions, not a class, just
> one simple function. That way, for the few people that need it, they can do
> $_POST = multipart_form_data_parse(file_get_contents(‘php://input')); and
> their problem’s solved.


> If we can’t expose the parser, we could also just add a function to force
> population (force_parse_post_data() or something?). Again, this allows the
> few that need this to do so explicitly, but doesn’t make $_POST allow it
> for everyone else.
>



While that solution solves one specific problem (dealing with multipart
form data of request types other than POST), it doesn't quite tackle some
of the broader issues of dealing with incoming HTTP request in PHP that I
would like to tackle. I also think you're diminishing scope of this problem
and the number of people affected by it. You not only have to think of the
number of programmers dealing with the code, but the number of end-users
indirectly affected by the problem as well. PHP is primarily a web-oriented
language, and I think as such it should deal with these kinds of issues
more readily. If you take a good look at the number of web-based APIs out
there and how certain PHP client libraries try to deal with these kinds of
problems the solutions are sometimes very poorly implemented or just
outright wrong.

We solved password hashing dilemmas with password_hash for a similar reason
in PHP. In that people were just doing it wrong and didn't know any better.
So I think making a more robust, and simpler interface to deal with these
kinds of issues will encourage people to get it right in the future.


> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

I'm not keen on the idea of adding more superglobals to PHP, although I
certainly understand the grave concern of breaking people's code and as
such I've chosen not to pursue the idea of removing superglobals.

I will, however, revisit the idea of exposing the underlying SAPI
callbacks, for handling the incoming HTTP request in PHP, to userland. From
a rough skim through the code, so far, it appears that this is already
entirely possible and shouldn't be very difficult to expose the SAPI API to
userland without breaking BC. This would make it possible for people to
register request handlers in the same way they can register autoloaders and
as such make it possible to handle things like PUT/MOVE/PROP FIND HTTP
requests through some custom callback.

The only concern there is would people prefer to use their own custom
callbacks in userland or would they prefer for PHP to do it for them?

>From all the people I've spoken with that have a problem with handling PUT
requests in PHP, it seems that they'd rather have PHP populate
$_FILES/$_POST automatically in this case. Which would be relatively easy
to do by modifying the default post reader function in the SAPI
http://lxr.php.net/xref/PHP_5_6/main/php_content_types.c#51 however, that
is itself a small BC break.

Does anyone have any recommendations on what they think the best approach
is? I'd appreciate any feedback/suggestions/constructive-criticism. Thanks!



On Mon, Nov 3, 2014 at 7:08 AM, Patrick ALLAERT 
wrote:

> 2014-10-30 19:23 GMT+01:00 Sherif Ramadan :
> > Hello Internals,
> >
> > I've been meaning to write up a full-blown RFC for introducing a new
> > standardized HTTP interface for PHP core for some time now. I figure now
> > with PHP 7 on the road map this might be a good time to start this
> > discussion since it involves breaking some backwards compatibility that
> may
> > have been out of the question in PHP 5.
> >
> > I've started a draft RFC, but please be patient as this is a working in
> > progress, here https://wiki.php.net/rfc/http-interface on the wiki.
> >
> > The point here is to allow users to implement their own HttpRequest and
> > HttpResponse classes that can deal directly with the raw request/response
> > messages in any way the user deems fit. This alleviates cases like "what
> > about when I want to have $_PUT or $_DELETE" and removes the ambiguity of
> > the $_POST, $_GET superglobals to a more conforming way of handling the
> > messages.
> >
> > Since it's an interface, it only dictates the facilitation of PHP's
> > built-in functionality and the user's desired implementation, but no the
> > implementation itself. To remove all confusion, consider the way an HTTP
> > message actually looks.
> >
> > GET /foo?bar=1 HTTP/1.1
> > Host: foobar.com
> >
> > baz=2
> >
> > Instead of treating this with current $_GET, $_POST, let's consider for a
> > moment how we might treat it in an HttpRequest object:
> >
> > If the HttpRequest class implements an HttpParameters object that parses
> > and treats the entire HTTP request line as a string of parameters we
> could
> > accomplish the following...
> >
> > var_dump(HttpRequest::$parameters->bar); // int(1)
> > var_dump((string) HttpRequest::$parameters); // string(6)"?bar=1"
> >
> > Now consider how the body can be treated...
> >
> > echo HttpRequest::$body; // baz=2
> > echo HttpRequest::$body->baz; // 2
> >
> > Since the HttpRequest object can lazily parse the body it can also lazily
> > apply custom filters directly to the request variables and parameters...
> >
> > For example, say you wish to treat baz only as an integer? This can be
> > easily accomplished by setting the filters directly in the HttpRequest
> > object and upon access the filter is directly applied to chosen
> variables.
> > This also alleviates the need to worry about overwriting superglobal
> > variables or having to copy from them. So from an efficiency stand-point
> > this approach works much better. It also allows you to separate clearly
> > between HTTP request parameters and HTTP request body as well as the HTTP
> > request method. Since the request object should be capable of handling
> > callbacks for each method to apply different sets of filters or rules on
> > treating the request body given different request methods this could
> prove
> > a lot more useful than existing techniques applied directly in PHP with
> > php://input, for example.
> >
> > We don't need to copy the internal stream and we don't need to modify or
> > copy

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 5:01 PM, Will Fitch  wrote:

>
>
>
> I’m actually not suggesting an alternative - I’m suggesting this RFC isn’t
> an option.
>
>

Great, your suggestion has been noted. Thanks for your contribution to this
discussion! :)

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 4:29 PM, Will Fitch  wrote:

>
> On Oct 31, 2014, at 4:21 PM, Sherif Ramadan 
> wrote:
>
>
>
> On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch  wrote:
>
>>
>>
>>
>> While not too specific to Rowan, reiterating the pecl/http approach is
>> indirectly what your asking for? I have mentioned this numerous times, but
>> you haven’t responded with a reason not to take this approach - which is an
>> RFC that was presented for discussion prior to yours.
>
>
> I'm trying to understand how pecl/http solves the aforementioned problem
> any better? Again, I have no problem with competing ideas and it's not as
> though one is prohibited from presenting an idea for the mere fact that
> there exists a competing one. I'm just not seeing how pecl/http solves the
> problem I intend to solve better. The reason I haven't responded to you yet
> is because I'm stilling weighing the two to try and make sense of whether
> or not these are in fact competing ideas or complimenting ones.
>
> Please, feel free to weigh in with anything that contradicts or concludes
> what I'm saying. I certainly don't expect to have all of the answers.
>
>
> What doesn’t pecl/http solve under your situation? The fact that’s it’s
> not directly integrated as part of ZE and handling process?
>


Well, you're the one suggesting an alternative. The onus is on you to prove
that it solves the same problem, not me. However, I'll bite for the
purposes of moving the discussion along...

As far as I understand, pecl/http attempts to solve a much larger scope of
problems than this RFC. Namely, dealing with HTTP messages in general,
whether they are a part of PHP's request/response model or not. i.e. there
is no direct integration of the PHP request into pecl/http and as such it
doesn't directly solve a problem such as properly parsing the HTTP request
body during a PUT request and properly populating the $_FILES/$_POST
superglobals. It also doesn't solve similar problems where a transport
message body is sent entirely in JSON to PHP and PHP is responsible for
handling.

Of course, yes, you can do accomplish this today with some hacks like using
the php://input stream, but it's only up until recently that this stream
has become reusable. It's also potentially creating some duplication, but
albeit this isn't the only problem.

This RFC also attempts to make it possible for users to directly apply
filters to input from the HTTP request so that they can simply retrieve the
fitlered data from the HttpRequest object directly without having to do
things like $foo = isset($_POST['foo']) ? filter_var($_POST['foo'],
FILTER_VAR_INT) : 0; // for example

I have nothing against pecl/http. I think it's a very useful library and
Mike seems to have put a great deal of work into it. I would gladly vote it
into PHP core. I'm just not clear on how it solves the same problems this
RFC attempts to solve. They can actually compliment each other in some
areas; I can see that.



>
> I certainly have no problem with competing ideas either. However, the only
> proposed patch in this RFC is a gist with PHP pseudocode.
>
>
>
>

It's not pseudocode since it's actually perfectly valid PHP code that will
compile and run in the PHP interpreter. However, it is intended to
demonstrate the behavior. The pecl/http RFC is also further along as it's
in discussion phase with an actual implementation. This RFC is merely a
draft, with no actual implementation proposed yet (but that's not at all
uncommon as many RFCs proposed in PHP did not provide an actual
implementation until after they were voted in: generators, list in foreach,
and finally are among a small number that come to mind). So let's not get
hung up on implementation being the barrier to entry for an RFC as that's
never ever been the case in the past.

It is, however, entirely understandable that the RFC should explain the
actual behavior and consequences as well as possible if it does not provide
an actual implementation. This is just a very early stage discussion to
gather ideas so that I can improve and finalize the RFC. I have not
actually placed the RFC into discussion or voting phase just yet. So let's
not put the cart before the horse.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch  wrote:

>
>
>
> While not too specific to Rowan, reiterating the pecl/http approach is
> indirectly what your asking for? I have mentioned this numerous times, but
> you haven’t responded with a reason not to take this approach - which is an
> RFC that was presented for discussion prior to yours.


I'm trying to understand how pecl/http solves the aforementioned problem
any better? Again, I have no problem with competing ideas and it's not as
though one is prohibited from presenting an idea for the mere fact that
there exists a competing one. I'm just not seeing how pecl/http solves the
problem I intend to solve better. The reason I haven't responded to you yet
is because I'm stilling weighing the two to try and make sense of whether
or not these are in fact competing ideas or complimenting ones.

Please, feel free to weigh in with anything that contradicts or concludes
what I'm saying. I certainly don't expect to have all of the answers.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 3:35 PM, Rowan Collins 
wrote:

> Sherif Ramadan wrote on 31/10/2014 18:52:
>
>> This RFC is about core PHP and I really don't care how
>> many competing ideas exist out there that are closely or mildly related to
>> this RFC.
>>
>
> The decision about *whether this is needed in core* is not something you
> can ignore by saying "this is about core". The fact that PHP-FIG is working
> on something very closely related to this makes a difference to that
> question, and pretending that's irrelevant is not constructive.
>
>
First of all, I'm not ignoring anything. I very much appreciate all of your
input. However, reiterating what you've already said with every single one
of your responses attempting to derail this discussion into a matter that
concerns FIG or PSR or whatever other third party concern that is
tangentially related to the word HTTP is something I will not stand for.

I read what you've had to say about FIG and PSR and I'm taking it into
consideration. That doesn't mean I have to yield to your preference. Nor
does that mean this RFC has now become irrelevant because somewhere on
planet earth someone has come up with a competing idea/concept. I welcome
competition. That is only beneficial to PHP.

If you would like to further this discussion beyond reiterating the words
PSR and FIG then please explain to me how what you're talking about solves
any of the problems I'm attempting to solve with this RFC? Namely, how does
this PSR solve the problem that PHP will not populate $_FILES or $_POST if
a multipart PUT request is sent to PHP? Pointing out specifics, using
references, and providing any additional examples/documentation is more
than welcome if it will help me improve this RFC (but only if it is geared
toward the same goals that this RFC has).

Thanks

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 3:00 PM, Larry Garfield 
wrote:

> On 10/31/14, 1:52 PM, Sherif Ramadan wrote:
>
>>
>>
>  This RFC has two primary goals in mind:
>>
>> 1) Expose the parsing/handling of the HTTP request to userland in a
>> consistent way
>>
>
> It already is. It's the access TO that parsed data that is currently
> clunky.  That's a problem worth addressing.


No, it's not. There is no way for you to prevent PHP from populating
superglobals, or change the way PHP mangles variable names, or change the
fact that PHP won't bother populating data in $_FILES or $_GET/$_POST when
the request method is PUT or if the content-type is not multipart, for
example. None of this is exposed to userland.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

So for the purposes of this discussion and in an effort to remain on-topic
and productive, let's keep all of the FIG/PSR and other third party efforts
out of the discussion unless it is intended to improve/help this particular
RFC. Please keep in mind that this is a PHP internals discussion and not a
FIG/PSR discussion. This RFC is about core PHP and I really don't care how
many competing ideas exist out there that are closely or mildly related to
this RFC.

This RFC has two primary goals in mind:

1) Expose the parsing/handling of the HTTP request to userland in a
consistent way
2) Avoid having the request parsed/mangled at multiple levels during the
request by presenting one central place to handle the parsing

These goals can not be achieved purely in userland, because you would
potentially have to do the parsing step twice. I wish to make it possible
for the user to override that with their own implementation just like they
can override the Session handler with the Session interface.

How we end up deciding to do that may change from my initial proposal, and
that's fine, but let's focus on that rather than getting off topic about
other third party efforts.

Thanks!

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 1:32 PM, Florian Margaine 
wrote:

> Hi,
>
> Le 31 oct. 2014 18:28, "Sherif Ramadan"  a écrit
> :
> >
> > On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins 
> > wrote:
> >
> > >
> > > Let me repeat my question:
> > >
> > > Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive",
> > > what do I then do with this class in order for it to perform any
> actions?
> > >
> > > How does PHP know that my class is the one it should populate, or when
> > > that population should happen?
> > >
> >
> >
> > It wouldn't. You would need to extend the base class, since it already
> > implements the necessary interface. PHP would simply call on the last
> > subtype of HttpRequest during the request init phase.
>
> What if there is multiple subtypes?
>
> class A extends HttpRequest {}
> class B extends HttpRequest {}
>
> What happens there?
>

As of now, all the subtypes would be called, i.e. if A has a receiveMessage
method, it would be handed the message, and if B has a receiveMessage
method it too would be handed the message. It's up to those methods to call
on subsequent parsing methods to do something with the message, obviously
any methods they don't implement are forwarded to the parent.

This clearly has some conflicts, like if default parsing is left we
overwrite superglobal variables. However, it also has benefits, in that we
can have multiple implementations for handling the request in the same code
base and it is left up to the user to decide which one to use.

So, again, this is still a draft and I'm open to suggestions about how to
handle/deal with such problems.




> > Of course, this is an
> > implementation detail as of now. There could certainly be other/better
> ways
> > to accomplish this. I just want to keep it as simple as possible for now
> > without introducing more configuration nightmares that people often
> > complain about. I really don't like the idea of adding yet another INI
> > directive to control this behavior (making it harder to port).
> >
> > What do you propose?
>
> Regards,
> Florian Margaine
>

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins 
wrote:

>
> Let me repeat my question:
>
> Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive",
> what do I then do with this class in order for it to perform any actions?
>
> How does PHP know that my class is the one it should populate, or when
> that population should happen?
>


It wouldn't. You would need to extend the base class, since it already
implements the necessary interface. PHP would simply call on the last
subtype of HttpRequest during the request init phase. Of course, this is an
implementation detail as of now. There could certainly be other/better ways
to accomplish this. I just want to keep it as simple as possible for now
without introducing more configuration nightmares that people often
complain about. I really don't like the idea of adding yet another INI
directive to control this behavior (making it harder to port).

What do you propose?

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 12:04 PM, Andrea Faulds  wrote:

>
>
>
> So there’s still a default implementation, then? So, if you want to parse
> in userland, how does that work? The default implementation fills in the
> variables and then your implementation parses it again, wasting CPU time
> and making the request take longer? Or does the default implementation do
> nothing at all unless asked to, breaking existing apps unless they’re
> modified to request parsing? Or is it INI-determined??
>

No, by overriding the parseBody or parseParameters methods, for example,
you can prevent the default behavior from happening. (i.e. it is not doing
the same thing twice). Simply by extending the HttpRequest class, we can
call on the child class instead. Any methods not implemented in the
extending class would be forwarded to the parent class as per normal PHP
inheritance rules.


>
>
> OK. So they’re just interfaces, then? In which case, why not leave the
> PHP-FIG to finish its HTTP Message proposal instead?
>
>
>
*snip*


> So, all you’re proposing is a set of interfaces, to compete with the work
> the PHP-FIG is doing.
>
> I don’t see how this is useful. How, exactly, does adding interfaces solve
> the problems with superglobals? Because you’re creating a common standard
> for alternative request implementations? But, we already have such a WIP
> standard in userland from the PSR people.
>
> I really don’t get this RFC. If this was to add implementations of the PSR
> Request/Response stuff, that might be useful. But merely adding new
> interfaces… I don’t get it. Why duplicate effort? How does this fix
> superglobals?
>
>

 Competing ideas are good and the very reason that drives innovation. This
proposal is for both the interface and the implementing class, which can be
extended to create custom behavior in handling the HTTP request/response. I
have no idea why you think PHP-FIG or PSR is involved in this conversation.
This is a PHP internals matter and should be considered for PHP internals
purposes. The benefits and cons of this proposal are pretty clear, I think.
You get the ability to handle different kinds of requests as you see fit or
you leave the default behavior intact and everyone wins.

The only thing you don't get if you do this in userland instead, is you
have to do the parsing of the message twice, which this RFC attempts to
circumvent, but offering a way to overrride the parser before parsing takes
place (if you choose to implement it).

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 12:19 PM, Andrea Faulds  wrote:

>
>
>
> I’m not sure I really see what it solves, though? Why should we allow
> users to implement their own slow parsers in userland? Why can’t we just
> have a single built-in parser like we’ve had the last two decades? I don’t
> see the point.
>
>
For one, it would solve the problem addressed by the bug report (
http://php.net/55815) listed in the RFC, where users are asking for
additional features to parse and handle different kinds of requests like
PUT, which PHP currently doesn't do. Additionally, it solves problems such
as filtering input from the request with a more abstract interface that
doesn't rely on modifying or copying globals. The implementation can be
devised to do filtering at the request level or even lazy-loaded so that
filters are only applied when the data is requested. In addition, you could
utilize this approach to apply different kinds of custom filters based on
the request type using the onReceive hook, for example. Further more it can
be used to ensure that the request data is immutable so that there is no
wonder if the superglobals have been modified/tainted. This is something
many frameworks try to abstract themselves in fear that someone might
accidentally modify the superglobal variables (as this is very easy to do
in userland).

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 11:56 AM, Rowan Collins 
wrote:

>
> I think the piece that's missing is how exactly these interfaces would
> interact with core, or rather with the SAPIs which handle the actual
> transfer of HTTP requests and responses.
>

PHP would have an HttpRequest class, as noted in the updated RFC, which
implements the HttpMessageReceive interface. The HttpRequest class's
default behavior would be to just populate the superglobals (i.e. having
the same net-effect as the current behavior).

If a user wanted to override that default behavior they would just extend
HttpRequest and implement the functions/methods they wanted to override.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Fri, Oct 31, 2014 at 5:25 AM, Andrea Faulds  wrote:

>
>
> This is no less of a backwards-compatibility headache. This still breaks
> every PHP app I have ever written.
>
>
To be perfectly clear, the default behavior would remain the same, so no
PHP app you have ever written would break. The difference is, you would now
be able to override any part of the default behavior by extending the
HttpRequest class in your own code.


>
>
> No no, I'm not concerned about the contents of the interface. I'm
> wondering what, exactly, this "interface" does? I don't see how a mere
> interface would replace the superglobals, unless you want a superglobal
> request object that anyone can swap out, which sounds like a bad idea.
>
>
The interfaces do exactly what you see here. They specified which methods
the HttpRequest and HttpResponse objects must implement.

If you bothered to invest nearly as much time in reading the updates to the
RFC as you did to making blanket statements and objections, you might
actually find less reason to respond with objections so abruptly. The
HttpRequest and HttpResponse classes are intended to provide a central
place for message handling behaviors and their properties can be used to
describe these behaviors.

So, if you wanted to support a $_PUT superglobal, rather than adding one to
the language, you can simply add the behavior to do the processing of PUT
requests in your HttpRequest class, by extending HttpRequest and defining
how PUT variables are handled there.


> --
> Andrea Faulds
> http://ajf.me/
>

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

So far there seems to be a lot of concern around BC, and particularly
removing or getting rid of GPC superglobals. So I completely understand the
concerns and hope to address them as clearly as possible.

First, for the sake of BC I think removing the superglobals from the
language should not be done here. Instead, for performance reasons, I'm
going to propose that the superglobals are not populated at the request
level. This means that the implementation is free to populate them at will
since they will still exist, but will be initialized to empty arrays by the
language.

Second, it's a valid concern that's there's no actual proposed interface.
So let me be begin by proposing a rough draft for one.

So let's consider the following interface layout and some sample
implementations as a start...

https://gist.github.com/srgoogleguy/f729053e3e88b2d2b3ec

Then let's consider the kind of flexibility this would allow userland in
terms of filtering, validating, and modifying the request data under
various conditions. Obviously, PHP has to provide some form of default
implementation so some base class HttpRequest can be implemented in PHP and
this can be easily extended by userland.

Also, take into consideration the kind of performance gains you might get
out of this by doing things like lazy-loading or lazy parsing or
lazy-filtering of request data. Filters also need not be applied at the
global level. PHP's default implementation would simply use the input
stream to populate GPC as normal (as it currently does), but I believe
introducing the base class will encourage others to make better use of
request/response handling in their own code.

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Oct 30, 2014 at 4:42 PM, Andrea Faulds  wrote:

>
> > On 30 Oct 2014, at 20:33, Sherif Ramadan 
> wrote:
> >
> > Yes, this proposal is intended to do two things. 1) Fix the
> aforementioned problems.
>
> By the sounds of things, it doesn’t fix these problems, it just adds a new
> interface which lacks them. That’s not the same thing.
>
>
No, the interface makes it possible to implement your own behavior, but it
does not prevent PHP from implementing default behavior. In that PHP would
implement its own HttpRequest class, for example, which the user can then
extend to override default behavior or modify it as they see fit for their
particular use case. This is much like the Session interface, which makes
it possible to change session storage mechanisms in userland, but still
have a confirming method of session handling in PHP.


> > 2) Improve upon the capabilities of PHP's request handling for future
> use cases through a unified interface.
>
> What unified interface? You’re allowing anyone and everyone to implement
> their own request handling.
>

Yes, by allowing this you make it extensible. However, having the interface
is what makes it possible to unify the efforts of dealing with the HTTP
messages both in userland and in PHP internals.


>
> > If you consider all of the major existing PHP frameworks today there is
> always some form of HttpRequest class handling these things and almost all
> of them do it slightly differently. What's worse, is they are all very
> inefficient implementations that I believe can be done far more efficiently
> in php-src. A lost of them are also unnecessarily complex. I think all of
> this can be simplified if the interface is just laid out in a
> straight-forward manner and then userland implementations will find less
> and less reason to over-engineer the implementation.
>
> The only reason an implementation of HttpRequest would be inefficient is
> because it has to work-around problems with $_GET and $_POST. Problems we
> could simply fix.
>

So the fix to something like PUT/DELETE requests is to add yet another
superglobal. However, this is still a very rigid fix that requires
continuous maintenance and fulfilling feature requests on the part of
internals. Think of implementing a new session handler for every session
storage mechanism in PHP. This is a lot of unneeded effort when we can just
expose the session interface to userland and make it extensible by nature.
The alternative is far more useful and less closed up (preventing future
problems to fix).

Let's not also ignore the fact that such features have been forsaken by PHP
internals for years. I have bug reports dating back to 2010 that have asked
for such features that have long been unanswered. So the current desire to
fix anything along these lines appears to be minimal, if not non-existent,
right now.


>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Oct 30, 2014 at 4:24 PM, Andrea Faulds  wrote:

>
> > On 30 Oct 2014, at 19:49, Sherif Ramadan 
> wrote:
> >
> > Well, let's look at how well providing implementation has worked out for
> > PHP so far.
> >
> > GPC variables are implementation. They pose rigidity to userland code
> for a
> > number of reasons. For example, if you do send a PUT request to PHP, PHP
> > will not bother populating GPC at all. Instead it leaves the user to
> define
> > their own handling from the input stream directly. If you do send
> GET/POST
> > requests to PHP, the variable names can be mangled and $_GET/$_POST are
> > treated differently for encoding as one is run through url_decode and the
> > other is not.
>
> We could just fix these problems rather than adding an entirely new
> implementation.
>


Yes, this proposal is intended to do two things. 1) Fix the aforementioned
problems. 2) Improve upon the capabilities of PHP's request handling for
future use cases through a unified interface.

To say that this proposal and fixing the aforementioned problems are two
distinct options (as in we can either fix these problems or go with this
proposal) is a very reductive form of thinking in which the only outcome
favors one party or the other.

My proposal is intended to result in a win-win situation where everyone
involved can be satisfied, not an ultimatum.

If you consider all of the major existing PHP frameworks today there is
always some form of HttpRequest class handling these things and almost all
of them do it slightly differently. What's worse, is they are all very
inefficient implementations that I believe can be done far more efficiently
in php-src. A lost of them are also unnecessarily complex. I think all of
this can be simplified if the interface is just laid out in a
straight-forward manner and then userland implementations will find less
and less reason to over-engineer the implementation.


> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

Re: [PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

On Thu, Oct 30, 2014 at 2:30 PM, Florian Margaine 
wrote:

>
>
> I find this very... useless. Sure, interfaces are not useless. But I don't
> think php-src is there to dictate what userland code should look like. It
> should provide *implementations*, not interfaces.
>

Well, let's look at how well providing implementation has worked out for
PHP so far.

GPC variables are implementation. They pose rigidity to userland code for a
number of reasons. For example, if you do send a PUT request to PHP, PHP
will not bother populating GPC at all. Instead it leaves the user to define
their own handling from the input stream directly. If you do send GET/POST
requests to PHP, the variable names can be mangled and $_GET/$_POST are
treated differently for encoding as one is run through url_decode and the
other is not. $_FILES is also an awkward one as the array is backwardly
multidimensional in that $_FILES['userfile'][$meta] are each partitioned
rather than having a more intuitive structure wherein one can iterate over
the $_FILES['userfile'] array directly.

Takeaway: PHP offering up implementation makes userland more rigid. PHP
offering up an interface makes userland inherently more appealing and
extensible. Take the session interface as one example where we one with
interface over implementation.


>
>
> The other thing I don't like in your RFC is the removal of superglobals.
> Sure, they're not the best interface out there, but breaking *every single*
> codebase out there is not the way to go. Especially if we don't want a
> perl6/python3-like failure to adoption.
>
>
I think pitting the Perl 6 and Python 3 scenarios as failure to adoption is
like lumping together the Betamax with the Blackberry. Perl 6 failed for a
number of reasons, not one of which was an effort to revamp antiquated
interfaces. Calling Python 3 a failure to adopt, is a bit ambitious. I
don't think people have failed to adopted Python 3.

I will tell you what will surely lead to failure, though. When we begin
ignoring the problem. Because then we are insisting that the proposed
solutions are useless since there is no problem to solve. There is an
evident problem in the way PHP handles the incoming Http Request and how it
makes it accessible to userland. Whether or not this solution is optimal
remains to be seen, but to say that the problem itself is non-existent is
pure denial without basis.

A failure to act is worse than an act of failure.


> Regards,
>
> --
> Florian Margaine
>

[PHP-DEV] New Standardized HTTP Interface

[Sherif Ramadan]

Hello Internals,

I've been meaning to write up a full-blown RFC for introducing a new
standardized HTTP interface for PHP core for some time now. I figure now
with PHP 7 on the road map this might be a good time to start this
discussion since it involves breaking some backwards compatibility that may
have been out of the question in PHP 5.

I've started a draft RFC, but please be patient as this is a working in
progress, here https://wiki.php.net/rfc/http-interface on the wiki.

The point here is to allow users to implement their own HttpRequest and
HttpResponse classes that can deal directly with the raw request/response
messages in any way the user deems fit. This alleviates cases like "what
about when I want to have $_PUT or $_DELETE" and removes the ambiguity of
the $_POST, $_GET superglobals to a more conforming way of handling the
messages.

Since it's an interface, it only dictates the facilitation of PHP's
built-in functionality and the user's desired implementation, but no the
implementation itself. To remove all confusion, consider the way an HTTP
message actually looks.

GET /foo?bar=1 HTTP/1.1
Host: foobar.com

baz=2

Instead of treating this with current $_GET, $_POST, let's consider for a
moment how we might treat it in an HttpRequest object:

If the HttpRequest class implements an HttpParameters object that parses
and treats the entire HTTP request line as a string of parameters we could
accomplish the following...

var_dump(HttpRequest::$parameters->bar); // int(1)
var_dump((string) HttpRequest::$parameters); // string(6)"?bar=1"

Now consider how the body can be treated...

echo HttpRequest::$body; // baz=2
echo HttpRequest::$body->baz; // 2

Since the HttpRequest object can lazily parse the body it can also lazily
apply custom filters directly to the request variables and parameters...

For example, say you wish to treat baz only as an integer? This can be
easily accomplished by setting the filters directly in the HttpRequest
object and upon access the filter is directly applied to chosen variables.
This also alleviates the need to worry about overwriting superglobal
variables or having to copy from them. So from an efficiency stand-point
this approach works much better. It also allows you to separate clearly
between HTTP request parameters and HTTP request body as well as the HTTP
request method. Since the request object should be capable of handling
callbacks for each method to apply different sets of filters or rules on
treating the request body given different request methods this could prove
a lot more useful than existing techniques applied directly in PHP with
php://input, for example.

We don't need to copy the internal stream and we don't need to modify or
copy superglobals around to different parts of our code.

I'm in the process of writing up a cleaner implementation to introduce in
the RFC, but in the mean time I'd like to open up to discussion and see
what others think or how they feel we might approach this problem more
cleanly.

Thanks,
Sherif

Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator

[Sherif Ramadan]

On Mon, Sep 8, 2014 at 4:06 AM, Michael Wallner  wrote:

> On 07/09/14 14:25, Andrea Faulds wrote:
>
> >
> > There’s actually a quite serious issue just now, which is that it
> > evaluates the first operand twice if it’s not empty. This is because
> > $a ?: $b is expanded to empty($a) ? $b : $a, such that if you did
> > something which mutates state in there, it’d happen twice. This is
> > obviously not good, and I’m going to figure out how to fix this.
> >
>
> This could very well be the reason why it is like it is today.
>
>
I agree. The more I think about, the more this seems weird. What if I
explicitly want to use ternary to check isset() and not empty?

Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736

[Sherif Ramadan]

Actually, we shouldn't be doing that all. We should simply just overwrite
the header. It wouldn't make much sense to set two headers with the same
cookie name when we can just overwrite it.


On Mon, Sep 8, 2014 at 2:50 AM, Tjerk Meesters 
wrote:

> Hi!
>
>
> On Sat, Sep 6, 2014 at 5:38 AM, Florian Margaine 
> wrote:
>
> > Hi,
> >
> > This is a minor BC break, but still a BC break, so worth discussing on
> this
> > ML.
> >
> > When a second setcookie() is done with the same name, a warning is
> emitted,
> > because the ietf rfc 6265 says it *should* only send one Set-Cookie
> header
> > per name.
> >
> > This is fine when display_errors is set to off. When it's set to on, the
> > warning prevents the header from being added because "headers already
> sent"
> > (which is the minor BC break, as current PHP just sends 2 Set-Cookie
> > headers with the same name).
> >
>
> Yeah, it would prevent any header() or setcookie() following that warning
> from taking place.
>
> How about delaying that warning until the headers are sent?
>
>
> >
> > So, should it be merged? What should be done to comply with the ietf rfc
> > 6265?
> >
> > PR: https://github.com/php/php-src/pull/795/
> > PHP issue: https://bugs.php.net/bug.php?id=67736
> >
> > Regards,
> >
> > *Florian Margaine*
> >
>
>
>
> --
> --
> Tjerk
>

Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator

[Sherif Ramadan]

I've played around with this branch for a bit and seems reasonable, passes
the tests, and doesn't seem to have any serious issues/memories leaks
AFAICT.

I can't stress enough, however, how important it is for us to avoid
inconsistencies in behavior between various forms of syntax. This is often
something users complain of as often they complain about not getting such
features. So let's make ternary consistent before we implement yet another
oddity in PHP (half-assed and ill designed).

I don't actually agree with the premise that ternary should wrap the first
operand in empty() to begin with, but if this is what people want, fine.
Let's just do it right.

And as Rasmus mentioned in the PR, make the documentation very _cleary_ if
it gets accepted.


On Sun, Sep 7, 2014 at 6:30 AM, Pierre Joye  wrote:

> Hi Andrea,
>
> On Sep 6, 2014 2:03 AM, "Andrea Faulds"  wrote:
> >
> > Good evening,
> >
> > I’ve written an RFC and working patch which attempt to add this feature
> which has been often requested: https://wiki.php.net/rfc/isset_ternary
>
> I did not look at the patch yet but I like it from a feature point of view.
> We should have had this since long :)
>
> Cheers,
> Pierre
>

Re: [PHP-DEV] Kill ereg with fire

[Sherif Ramadan]

+1

Kill it with fire and throw more gasoline ontop of the fire.


On Sun, Aug 31, 2014 at 8:08 AM, Tjerk Meesters 
wrote:

> Hi Ferenc,
>
> On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs  wrote:
>
> >
> >
> >
> > On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters <
> tjerk.meest...@gmail.com> wrote:
> > Hi internals (again),
> >
> > Recently I’ve done a small assessment on how feasible it is to remove
> ext/ereg from the project for the next major version. This is the result
> (so far):
> >
> > https://github.com/datibbaw/php-src/compare/kill-ereg
> >
> > I’ve replaced two instances of ereg with their pcre equivalents, OPcache
> and PGSQL.
> >
> > Btw, simply using ‘pcreposix.h’ didn’t work out for OPcache, I would get
> this error:
> >
> > Error Blacklist compilation: invalid argument to regex routine
> >
> > Perhaps I’ve missed something obvious, but porting it wasn’t hard either.
> >
> > Thoughts?
> >
> > Afair we have a patch floating around, but never made it into the repo,
> but everybody seemed to agree to remove the core dependency of ereg and
> make it optional to enable.
>
> You mean make it optional to install via PECL, right? I agree ;-)
>
> Package maintainers can always choose to ship their php packages with ereg
> as a means to keep supporting it, regardless of how it’s provided (bundled
> or PECL).
>
> >
> >
> > --
> > Ferenc Kovács
> > @Tyr43l - http://tyrael.hu
>
>

[PHP-DEV] Remove requirement to escape delimiters in regular expression in PCRE functions

[Sherif Ramadan]

Hi,

Someone pointed out to me recently that since the delimiters are not a
requirement of PCRE, and thus should not be considered a part of the
regular expression, there really is no need to escape them inside of the
regular expression such as that provided to preg_match functions and
similar.

I propose removing this requirement by seeking out the delimiter from the
end of the regex string (ignoring modifiers) and working backwards to find
the closing delimiter. Currently the implementation seeks out the closing
modifiers by iterating through the entire regex string from start to end
(thus requiring us to escape the delimiter inside the expression).

The change introduces no BC breakage as far as I can tell and offers a
number of advantages.

1) Regular expressions supplied to preg_match functions become portable
across PCRE implementations since escaping the delimiter inside of the
regular expression really isn't required. (i.e. it may work from PHP to
Perl, but may not work from Perl to PHP). This makes things a lot easier to
port between PHP and other PCRE implementations.

2) The regular expression is easier to read by a human if we remove the
requirement to escape delimiters.

3) It becomes clearer that the delimiters are not a part of the regular
expression both in the implementation and from userspace code.

It's not a big change so I propose merging into 5.5 or 5.4 up into 5.5.

Thoughts, objections, etc?

Re: [PHP-DEV] PR 287 - added use_keys argument to array_filter() [Discussion]

[Sherif Ramadan]

On Thu, Sep 26, 2013 at 7:33 PM, Tjerk Meesters wrote:

>
>
>
> I didn't quite understand how the current implementation would have BC
> issues, though. Would you care to elaborate on that?
>
>
>

I didn't look at your actual implementation. I saw 3 constants and deduced
that one would be required. If it was the case that there was a default to
values then there is no BC, but it's cleaner to just have two constants
here with the default behavior being values.

Re: [PHP-DEV] PR 287 - added use_keys argument to array_filter() [Discussion]

[Sherif Ramadan]

On Thu, Sep 26, 2013 at 6:51 PM, Tjerk Meesters wrote:

>
>
> I deliberately chose these values so that I can simply specify `true` to
> mean pass both values. Bit masks seem cumbersome in this situation.
>
>

The default behavior is already to pass the value to the callback.
Requiring the argument only breaks backwards compatibility here. There is
no need for introducing 3 new constants. Simply use PASS_KEY or PASS_BOTH
to solve this problem with the default behavior is pass value if the
argument is omitted.

Re: [PHP-DEV] VCS Account Request: requinix

[Sherif Ramadan]

On Wed, Aug 7, 2013 at 10:29 PM, Damian Wadley  wrote:

> I like how all the \"why I need a Git account\" reasons above
> are copied verbatim from the list of reasons one *doesn\'t* need a Git
> account :)
>
>
Well, you passed the first test.

Re: [PHP-DEV] Operator precedence is undefined?

[Sherif Ramadan]

After some digging and a little more thought I find that removing this
comment from the example in the docs at
www.php.net/language.operators.precedence does indeed cause more harm than
good. So I'm definitely wrong in saying that it should be removed.

However, I would like to acknowledge the confusion evident in bug 65087 and
offer some clarifying language and examples that may assist future users as
well as bring some closure to this bug report.

As pointed out to me on IRC PHP has exhibited changes in this behavior
between PHP < 5.1.0 and PHP >= 5.1.0 where the order of evaluation is not
well-defined. The example states that  ++$a + $a++ may result in 4 or 5 and
that the behavior is undefined. This by itself seems confusing to the user
since they always see 4. What's not clear is that this isn't typical
everywhere in PHP.

For example:

$i = 0;
$i = $i++;

Here $i is always 0, but again the behavior is undefined because in the
following code it is not clear what happens:

$i = 0;
$arr = array();
$arr[$i] = $i++;
var_dump($arr);

According to  the above code produces the following result between PHP
4.3.1 and 5.5.1

array(1) { [0]=> int(0) }

Where as the same code produces a very different result between PHP 5.1.0
and above:

array(1) { [1]=> int(0) }

The same happens with preinc/dec operators as well

$i = 0; $arr = array(); $arr[$i] = ++$i; var_dump($arr);

PHP < 5.1.0

array(1) { [0]=> int(1) }

PHP >= 5.1.0

array(1) { [1]=> int(1) }


The problem is I'm not sure where this type of information should be
documented. It makes sense to put this on the increment/decrement operators
page, but doesn't seem appropriate the operator precedence page. So to make
sure we're all in agreement I'm suggesting the following language to be
added as a note on the increment/decrement operators page at
www.php.net/language.operators.increment with supplement examples provided
above to help users get a better understanding of what we mean when we say
undefined behavior and add an additional warning box not to rely on this
type of behavior.

"As noted from the examples above the use of multiple increment/decrement
operators in the same expression is considered undefined behavior because
the order of evaluation cannot be guaranteed. Using such evaluations may
lead to unexpected results."

"Warning:
Relying on this behavior is discouraged as it may be subject to change and
without notice. Results are not typical and are implementation-specific."

If anyone feels that could use a little more clarity or can be reworded
better let me know. Thanks.

Re: [PHP-DEV] Operator precedence is undefined?

[Sherif Ramadan]

On Sat, Jul 20, 2013 at 3:37 AM, Stas Malyshev wrote:

> Hi!
>
> > I cannot believe this is true now, but I ask list before I fix doc.
>
> I don't think there's something that needs to be fixed. "Undefined"
> means "it depends on implementation and we do not want to commit to a
> specific behavior here because implementations may change". This is a
> fair warning against using implementation details that are not promised
> to stay fixed and later crying why next PHP version broke your code.
> Because you used undefined behavior. If the behavior is specified as
> undefined, that means "don't do this" - so you know it may be broken,
> and write better code instead that is not broken.
>
>

Stas,

I agree that we should not rush to commit changes in the midst of on-going
discussion. However, I have to just add to this notion of undefined
behavior that by your definition ALL of PHP is undefined behavior.
Everything we do is an implementation detail. What specification do we have
that clearly defines PHP's behavior? Can you honestly tell me that we
haven't changed behavior in the past despite no clear warning of "undefined
behavior" in the manual? References being one example.

I'm just suggesting that we carefully consider our arguments and not only
acknowledge them when they work out to our benefit and then discard them
the moment they don't support our cause. Clearly there is an argument here
that this is acceptable behavior and clearly there is an argument that it
is undefined. The real question is whether or not its worth specifying as
"undefined behavior" in the manual. A single line comment in an example
like that which states "may print 4 or 5" is not good documentation. My
suggestion is either clarify in an actual note or section of that
documentation why it is considered undefined behavior or to remove the
comment.

There is unquestionable signs of confusion coming from our users as the bug
report indicates. We should not ignore the fact that this comment has
confused somebody and should instead strive to improve it.

My suggestion would be to ad some clarifying language here:

"Using multiple increment/decrement operators in the same expression has
no guaranteed order of resolution and is subject to change. Relying on code
such as $a = 1; ++$a + $a++ === 4; is considered undefined behavior."

Re: [PHP-DEV] Operator precedence is undefined?

[Sherif Ramadan]

On Sat, Jul 20, 2013 at 1:33 AM, Sara Golemon  wrote:

> Your example "-$a * $a" isn't at all the same because -$a doesn't produce
> side-effects, only output.
>

It doesn't have side effects. This is true. So I retract my argument there.


>
> I never said that the compiler might magically produce differing results
> for the same input.  I said that the language's definition does not declare
> a defined behavior for such expressions with combined side effects.
>

While this is very true it's also a matter of discretion, because the
language doesn't clearly define a lot of things. In fact, one can argue
that there is no language definition at all since PHP doesn't even have a
spec. Though I'm trying to take common sense into consideration and make an
exception that in this case I don't see where removing the comment of
undefined behavior is going to necessarily cause more harm than good. Since
in the case of undefined behavior people will be left to wonder (why
doesn't ever seem to print 5?) We should either elaborate on why it *might*
print 5 in a full note on that page or we should remove the comment
completely. I oppose a documentation that leaves much room for clarity.

But perhaps for me it was easier to suggest removing the comment than
trying to clarify on why the behavior is undefined.


>
> As to reverting commits.  When the initial commit was made in haste during
> an active discussion, a revert is entirely appropriate and has nothing to
> do with placing one's opinion over another's.  It has to do with placing
> the process of consensus building over unilateral cowboy commits.
>

Fair enough.


>
> -Sara
>
>
> On Fri, Jul 19, 2013 at 10:08 PM, Sherif Ramadan 
> wrote:
>
>>
>> Sara,
>>
>> On Sat, Jul 20, 2013 at 12:44 AM, Sara Golemon  wrote:
>>
>>> What's undefined isn't the relationship between preinc/postinc and add.
>>>  What's undefined is the use of multiple preinc/postinc operators within a
>>> single expression
>>>
>>
>> I'm sorry but I can not find any evidence of how that is undefined. The
>> operators are right-associative, with a defined level or precedence. Their
>> operands are well defined and their return value in the expression is
>> determined by the compiler, not the parser. In this sense the compiler
>> always executes those opcodes first and returns a temporary variable.
>>
>>
>>> (preincrements in particular).  Our parser grammer, as it currently
>>> stands, does have a predictable order, but that is a side-effect of
>>> implementation.  The language's definition of order of resolution of
>>> multiple preinc/postinc elements within a single ticked statement is that
>>> they are undefined.  And *that* is what made your *particular* change to
>>> the documentation incorrect.
>>>
>>
>> The parser grammar in general is pretty muddled, I will agree with that.
>> However, the precedence order here is well defined within the expression. I
>> can not see any condition under which the compiler will introduce
>> unpredictable order of these opcodes or their results.
>>
>>
>>>
>>> If you'd like to define behavior for:  echo ++$a + 1;  then that's a
>>> different matter.  Defining the behavior of ++$a + $a++, however is
>>> inviting misunderstanding*.
>>>
>>> What was inappropriate, was asking for comment, receiving comment which
>>> cited an issue, then committing without discussing that issue first.
>>>
>>> -Sara
>>>
>>> * Even if, technically, either order of evaluation will result in the
>>> same answer for this contrived expression.  ++$a * $a++ is a more obviously
>>> ambiguous answer for a language which explicitly does not define an order
>>> of resolution.
>>>
>>
>> By that logic we should indicate that -$a * $a is also undefined
>> behavior? I know the parser grammar is not well-defined and I'm taking this
>> fact into consideration, but here we are talking about operators which will
>> compile down into very much well-defined opcodes and have a predictable
>> order of resolution. It's quite possible that someone could introduce a
>> change later on that will cause a different result, but the likelihood of
>> that becoming a reality is slim-to-none.
>>
>> I'm not a fan of getting into cat and mouse games over these types of
>> discussions, however. I posed my opinion on this matter and I refuse to
>> overwrite someone's commit because I feel my opinion is the only one t

Re: [PHP-DEV] Operator precedence is undefined?

[Sherif Ramadan]

Sara,

On Sat, Jul 20, 2013 at 12:44 AM, Sara Golemon  wrote:

> What's undefined isn't the relationship between preinc/postinc and add.
>  What's undefined is the use of multiple preinc/postinc operators within a
> single expression
>

I'm sorry but I can not find any evidence of how that is undefined. The
operators are right-associative, with a defined level or precedence. Their
operands are well defined and their return value in the expression is
determined by the compiler, not the parser. In this sense the compiler
always executes those opcodes first and returns a temporary variable.


> (preincrements in particular).  Our parser grammer, as it currently
> stands, does have a predictable order, but that is a side-effect of
> implementation.  The language's definition of order of resolution of
> multiple preinc/postinc elements within a single ticked statement is that
> they are undefined.  And *that* is what made your *particular* change to
> the documentation incorrect.
>

The parser grammar in general is pretty muddled, I will agree with that.
However, the precedence order here is well defined within the expression. I
can not see any condition under which the compiler will introduce
unpredictable order of these opcodes or their results.


>
> If you'd like to define behavior for:  echo ++$a + 1;  then that's a
> different matter.  Defining the behavior of ++$a + $a++, however is
> inviting misunderstanding*.
>
> What was inappropriate, was asking for comment, receiving comment which
> cited an issue, then committing without discussing that issue first.
>
> -Sara
>
> * Even if, technically, either order of evaluation will result in the same
> answer for this contrived expression.  ++$a * $a++ is a more obviously
> ambiguous answer for a language which explicitly does not define an order
> of resolution.
>

By that logic we should indicate that -$a * $a is also undefined behavior?
I know the parser grammar is not well-defined and I'm taking this fact into
consideration, but here we are talking about operators which will compile
down into very much well-defined opcodes and have a predictable order of
resolution. It's quite possible that someone could introduce a change later
on that will cause a different result, but the likelihood of that becoming
a reality is slim-to-none.

I'm not a fan of getting into cat and mouse games over these types of
discussions, however. I posed my opinion on this matter and I refuse to
overwrite someone's commit because I feel my opinion is the only one that
counts. I am certainly not above being wrong. I just want to be sensible.


>
>
> On Fri, Jul 19, 2013 at 9:28 PM, Yasuo Ohgaki  wrote:
>
>> Hi Sara,
>>
>> 2013/7/20 Sara Golemon 
>>
>>> On Fri, Jul 19, 2013 at 7:16 PM, Yasuo Ohgaki wrote:
>>>


 If there aren't comments, I'll rewrite the example.


 There were comments.  I explicitly told you that that the behavior is
>>> defined as undefined.  You CHOSE to ignore that comment.  You CHOSE to
>>> break the documentation.
>>>
>>
>> If there is defined precedence, arithmetic operation should follow it.
>> If there is exception, it should be documented.
>>
>> I don't understand why/how the arithmetic operation can be
>> ambiguous with defined precedence. (++ and -- are higher than +)
>>
>> $a = 1;
>> echo ++$a + $a++;
>>
>> should always print 4 with current PHP precedence definition.
>>  If it does not, it's a bug in language.
>>
>> // mixing ++ and + produces undefined behavior
>> $a = 1;
>> echo ++$a + $a++; // may print 4 or 5
>>
>> I don't see any reason it became undefined.
>> If this kind of simple precedence is broken, how programmers write
>> code and/or trust the language?
>>
>> http://3v4l.org/mR4da/vld#tabs
>>
>> This site seems support PHP 4.3.0 to PHP 5.5.0 and opcode looks
>> fine. Am I missing something?
>>
>> If you would like to suggest use of (), it should be done differently.
>> IMHO.
>> The comment only ruins PHP's reputation as language.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>
>

Re: [PHP-DEV] Operator precedence is undefined?

[Sherif Ramadan]

On Fri, Jul 19, 2013 at 11:56 PM, Sara Golemon  wrote:

> On Fri, Jul 19, 2013 at 7:16 PM, Yasuo Ohgaki  wrote:
>
>>
>>
>> If there aren't comments, I'll rewrite the example.
>>
>>
>> There were comments.  I explicitly told you that that the behavior is
> defined as undefined.  You CHOSE to ignore that comment.  You CHOSE to
> break the documentation.
>

With all due respect, how is the behavior undefined? Our parser defines the
precedence of those operators being higher in the precedence table than the
ones mentioned. The post inc/dec operators are also well-defined in
returning their values "Returns $a, then increments $a by one." at
www.php.net/language.operators.increment

I present the source as well
http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#1196

I'm confused about why you believe this is undefined behavior? Perhaps you
can elaborate on why this should be left in the documentation as undefined
despite what I believe to be clear evidence of definition. I don't see
"discouraged behavior" and "undefined behavior" to be synonymous. I do feel
it's OK to place notes/warnings in the manual about discouraged behavior,
however, just as we do with nesting ternary operators.

Re: [PHP-DEV] Operator precedence is undefined?

[Sherif Ramadan]

On Fri, Jul 19, 2013 at 10:36 PM, Yasuo Ohgaki  wrote:

> Hi Sheif,
>
> 2013/7/20 Sherif Ramadan 
>
>> Then I would say that example is wrong, but people may find reason to
>> disagree. I'm basing my contention purely off what I see in php-src and the
>> documented behavior for those operators. To me I see no reason why this
>> behavior would be considered undefined. The ternary operator definitely has
>> some undefined behavior in terms of precedence since its interpreted as a
>> statement and not like other operators in expressions. To me post/pre
>> inc/dec are pretty well-defined.
>>
>
> I wasn't going to document ambiguity, but ?:
> operator's association difference between C and PHP.
> It's a common pitfall for C programmers when they use nested ternary
> operators.
>

Yea, I believe the documentation at php.net/ternary already advices against
nesting ternary in PHP. Honestly, I don't know how you would even put
ternary into the precedence table given that it reads more like a statement
and less like an operator. Just look at the implementation in the parser
and you will be left in wonderment.

Re: [PHP-DEV] Operator precedence is undefined?

[Sherif Ramadan]

On Fri, Jul 19, 2013 at 10:16 PM, Yasuo Ohgaki  wrote:

> Hi Sherif,
>
> Thank you for your info!
>
> 2013/7/20 Sherif Ramadan 
>
>> I don't see where there is a bug in the documentation, no.
>
>
> It is in doc's example code.
>
>

Then I would say that example is wrong, but people may find reason to
disagree. I'm basing my contention purely off what I see in php-src and the
documented behavior for those operators. To me I see no reason why this
behavior would be considered undefined. The ternary operator definitely has
some undefined behavior in terms of precedence since its interpreted as a
statement and not like other operators in expressions. To me post/pre
inc/dec are pretty well-defined.

I would say there is no harm in removing that comment from the
documentation.

Re: [PHP-DEV] Operator precedence is undefined?

[Sherif Ramadan]

On Fri, Jul 19, 2013 at 8:55 PM, Yasuo Ohgaki  wrote:

> Hi Sara,
>
> 2013/7/20 Sara Golemon 
>
> > I would ask that you don't "fix" the docs, as we want to continue to
> > discourage users from engaging in unsafe behaviors.
>
>
> If precedence is implemented correctly, there should not be any ambiguity.
> If precedence is not implemented correctly, I suppose it is a bug as ++/--
> have
> much higher precedence.
>

I don't understand how it's a bug. Precedence is implemented correctly and
works as I'd expect it to. Here's the proof

http://3v4l.org/mR4da/vld#tabs

If you run this code through VLD you see that the opcodes clearly execute
both increment operators before the addition operator. This seems to hold
true from PHP 4.3.0 to 5.5.1 according to 3v4l.org. After all they do have
higher precedence in the precedence table.

$a = 1;
++$a // $a is now 2
$a++ // $a is still 2 and returns its value then increments to 3 (it's a
POST increment)
2 + 2 // The result is clearly 4

I would say that the behavior of these operators and their precedence is
very much well-defined. I don't see what the confusion.


>
> We don't want such docs nor bugs, don't we?
> Anyone know if the doc is correct or not?
> Thanks in advance.
>
>
I don't see where there is a bug in the documentation, no.


> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Feature Proposal: Allow letter decrementing

[Sherif Ramadan]

On Thu, Jul 18, 2013 at 7:18 PM, Chris London  wrote:

> I hear Perl 6 supports Str decrementing
>
>
I heard of Perl 6 once.

Re: [PHP-DEV] Pull requests report (17/7/2013)

[Sherif Ramadan]

On Thu, Jul 18, 2013 at 3:54 AM, Lior Kaplan  wrote:

> On Thu, Jul 18, 2013 at 4:21 AM, Sherif Ramadan 
> wrote:
>
>> On Wed, Jul 17, 2013 at 6:47 PM, Lior Kaplan  wrote:
>>
>>> What do you think about closing older PR ( > 28 days) ?
>>>
>>
>> First off, thanks for all the hard work. PRs aren't getting as much
>> attention as they should, and I'd like to say that I certainly haven't been
>> helping as much as I should with them. What I am noticing though, is that a
>> lot of these newer PRs, or the ones that are getting more attention, seem
>> to be fairly cosmetic changes. I mean, spelling mistakes are all great
>> fixes, and no disrespect to any contribution small or big, but there are
>> certainly a lot of PRs which people have spent a great deal of time working
>> on, clearly, that seem to be getting ignored. If we start closing these
>> strictly because of how long they've been open it would be such a
>> discouragement to everyone who contributed. I sincerely hope this doesn't
>> happen. I'd much rather see people spending more time on reviewing some of
>> the older PRs and seeing if they're worthy of merging or not based on
>> substance rather than just dismiss them based on how long they've been open.
>>
>> I've tried to get in contact with some of the original authors of at
>> least a couple of PRs in the past weeks to see if they were interested in
>> working on an RFC to get their PRs merged as they necessitated some more
>> discussion, but so far have come up empty. So I'll try to help out as much
>> as I can with the ones that can get immediate attention.
>>
>
> I'm glad to see that question got everyone's attension (:
>
> Indeed we started with the easy ones... there isn't any reason simple
> patches
> won't get merged very quickly.
>

No disagreement about doing what can be done.


>
> We have some PR which the disscussion about them is stuck, the question is
> who
> and when do we cut it off and send the author to rework his patch. After
> some
> feedback was given, if the author isn't responsive, and no one else wants
> to
> handle the patch instead, we can reject and ask them to come back when
> ready.
>
>
As you can see from my example (of which are are numerous others), the
author did everything that was asked of them. Yet, surprisingly, some
people only seem to have something to add to the discussion when there is a
problem (no harm there in pointing out problems with the patch), but are
nowhere to be seen when there is nothing left to be critical of (definite
bad on our part for not following up after the author did their part).


> Also, we have more than a few PR which the patch is OK, but are stuck due
> to a
> missing test. This is fair enough, but should also have some rule of thumb
> for
> these cases.
>

True, a lot of people either don't know how to write tests or don't like to
write tests for our test suite. They also might not know how to fix the
test in some cases where changing existing tests in necessary. This isn't
just limited to contributors not members of the PHP project, but even those
that have been long time contributors have come to me with a request to
either fix or write the test for them. I'll admit it took me a bit to get
the hang of phpt's work flow.


>
> Seeing a long list of PR waiting for a year isn't much encouraging, I
> would
> prefer to see people quickly either have their changes accepted,  sent to
> improve
> the PR or completly rejected. Don't forget the PR can always be resent and
> the
> work isn't lost.
>

Seeing PRs closed because no one cares to look at them is not ideal either.
I agree that we should respond as quickly as possible, but sometimes
changes being submitted require a bit more discussion on internals and
people seem reluctant to take this step. I can't blame them, internals can
be quite intimidating.

I, myself, have experience the pain-staking work it takes to get my PRs
merged into php-src, in the past. It took me nearly 6 months for some, and
some sat stagnate for longer until I decided to close them myself since the
people requesting the feedback never seemed to get back to me after
feedback was provided.

The process of getting PRs merged is definitely an on-going challenge due
to limited man-power and factors of impeding communication. No doubt about
that. I do not fault anyone in particular. I'd just like to see that
everyone gets a fair shot and no one is excluded for the sake of exclusion
or quickly drilling down the open PR list.

Re: [PHP-DEV] Fixes for documentation in source. Which branch to start?

[Sherif Ramadan]

On Thu, Jul 18, 2013 at 1:37 AM, Pierre Joye  wrote:

> On Thu, Jul 18, 2013 at 6:19 AM, Sherif Ramadan 
> wrote:
> > On Wed, Jul 17, 2013 at 11:55 PM, Yasuo Ohgaki 
> wrote:
> >
> >> Hi all,
> >>
> >> Take a look at this PR
> >>
> >> https://github.com/php/php-src/pull/351.diff
> >>
> >> The documentation in php.ini-* is broken, where should we
> >> fix these kind of error?
> >>
> >> From 5.3 branch or 5.4 branch?
> >>
> >
> >
> > 5.3 is security fixes only.
>
> Well, I don't see a good enough reason not to commit documentation to
> 5.3 as well
>

I suppose you're right since it's not source code, but it remains dubious
that this counts as documentation. If we want to add documentation notes
for this it should go in the manual where we document everything. Not that
I'm the arbiter of what goes in 5.3.


>
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>