On Tue, 18 Jun 2019 at 20:37, Mark Randall wrote:
> On 18/06/2019 18:53, Nikita Popov wrote:
> > This is not really possible, because we need completely accurate type
> > information. phpstorm-stubs is a good approximation especially when it
> > comes to "useful" return types, but it doesn't
On Sat, 15 Jun 2019 at 23:57, Marco Pivetta wrote:
> On Sat, Jun 15, 2019, 23:53 Wes wrote:
>
> > Hello PHP, I just published
> >
> > https://wiki.php.net/rfc/alternative-closure-use-syntax
> >
> > I would love your opinion on this
> >
> > I know it seems overkill and wrong to have two
On Fri, 14 Jun 2019 at 19:21, Sara Golemon wrote:
> On Fri, Jun 14, 2019 at 12:15 PM Benjamin Morel
> wrote:
>
> > I'm wondering if there's any reason why array_merge() doesn't allow zero
> > arrays to be passed?
> >
> > array_merge(); // Warning: array_merge() expects at least 1
>
On Fri, 14 Jun 2019 at 14:31, Joe Watkins wrote:
> Hi Christoph,
>
> I'm not even certain this needs to be put to a vote ... we should not be
> shipping that.
>
> +1 whatever ...
>
> If you can't find a single dissenting voice, just get rid of the thing
> before the next alpha, or possibly the
On Wed, 12 Jun 2019 at 18:16, Bishop Bettini wrote:
> On Wed, Jun 12, 2019 at 11:35 AM G. P. B.
> wrote:
>
>>- PharData::setAlias, PharData::setDefaultStub and PharData::setStub
>>always throw PharException
>><https://www.php.net/manual/en/class.ph
Hello internal,
I've been going through the documentation again to remove mentions of PHP 4
and found some extensions, functions, etc. on which I'd like to know the
state of them and if it would be wise to deprecate them.
I know I've thrown in some function aliases again, but only those which I
On Thu, 6 Jun 2019 at 10:54, Nikita Popov wrote:
> Hi internals,
>
> The https://wiki.php.net/rfc/consistent_type_errors RFC resolved one of
> the
> big differences in argument handling between internal and userland
> functions. This change allowed us to add return type information (available
>
On Wed, 29 May 2019 at 17:48, Theodore Brown wrote:
> On Wed, May 29, 2019 at 6:34 AM G. P. B. wrote:
>
> > I share the same concerns as Rowan Collins
>
> From my reading of Rowan's email, he was making a general point that
> new features can have a cost of added com
Moreover please use the bug tracker to raise such errors instead of mailing
the internal list.
Best regards
George P. Banyard
I share the same concerns as Rowan Collins, and I'm really not a fan of the
RFC in general.
Also I think those kind of magic numbers should be constants with
meaningful names, and it that case you could just compute them by adding
powers of ten.
E.g. DISCOUNT_IN_CENTS = 1 * 10^5 + 3 * 10^4 + 5 *
On Tue, 21 May 2019 at 14:17, G. P. B. wrote:
> I think I'll add a small note to the doc and an example showing the
> difference in behaviour as it seems pretty berried in the examples (the 4th
> one to be precise atm).
>
Added a note in the doc:
http://svn.php.net/viewvc?view=rev
On Tue, 21 May 2019 at 13:40, Christoph M. Becker wrote:
> On 21.05.2019 at 12:54, G. P. B. wrote:
>
> > On Tue, 21 May 2019 at 10:29, Nikita Popov wrote:
> >
> >> On Sat, May 18, 2019 at 9:37 PM Dik Takken wrote:
> >>
> >>> Good point. I
On Tue, 21 May 2019 at 10:29, Nikita Popov wrote:
> On Sat, May 18, 2019 at 9:37 PM Dik Takken wrote:
>
>> On 17-05-19 22:52, G. P. B. wrote:
>> >
>> > So as a side note aren't there maybe some other array functions which
>> > behave like this?
&g
On Tue, 21 May 2019, 06:42 Scott Dutton, wrote:
>
> Not sure if I can add and example to the RFC at this point, but I came
> across another example of this recently.
>
>
> https://gist.github.com/iansltx/4820b02ab276c3306314daaa41573445#file-getlines-php-L9
>
> // bindec() was doing weird
On Sat, 18 May 2019 at 21:37, Dik Takken wrote:
> On 17-05-19 22:52, G. P. B. wrote:
> >
> > So as a side note aren't there maybe some other array functions which
> > behave like this?
> >
>
> Good point. I did a quick scan of the source code and came up wit
On Fri, 17 May 2019 at 21:53, Dik Takken wrote:
> Hello,
>
> I just created a pull request that changes the array_merge /
> array_merge_recursive functions such that they allow being called
> without arguments:
>
> https://github.com/php/php-src/pull/4175
>
> This is my first attempt to
Evening internals,
I am not going to go into the details of every email which got sent in the
past two days as I am busy with Exam revision.
Main take away that I got from the previous emails:
1. No discussion:
It is indeed true that there hasn't been a lot (to not say none) of
discussion after
On Mon, 29 Apr 2019 at 16:53, Zeev Suraski wrote:
> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd
> wrote:
> > Please stop doing this.
>
> I will gladly do so, once the project starts behaving responsibly again.
>
Honnestly, this comment right here Zeev just makes me want to not
compromise at
On Sun, 28 Apr 2019 at 14:36, Zeev Suraski wrote:
> As I said numerous times in the past, I'm a firm believer that
>>> controversial RFCs (ones that generate a lot of votes with a substantial
>>> number of opposers) should not pass. I think this is important when
>>> adding
>>> features - but
On Sun, 28 Apr 2019 at 10:01, Zeev Suraski wrote:
> On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis wrote:
>
> > Also imo the reason why people write now (and not in the discussion
> > phase) because for some time in the voting there wasn't the 2/3 majority
> > for the 7.4 (so no sense to
On Thu, 25 Apr 2019 at 09:15, Nikita Popov wrote:
> Hi internals,
>
> As already discussed in the corresponding voting thread, the deprecation of
> short tags as proposed has a high risk of causing inadvertent source code
> leakage. The RFC proposes to change the default of short_open_tag from
On Wed, 24 Apr 2019 at 14:20, Andreas Hennings wrote:
> Hello list,
> I assume this is only about I do not see this distinction mentioned in the RFC, perhaps I missed it? I
> think it would be useful to make this explicit, to avoid possible
> confusion.
>
> G. P. B. schri
Hello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.
The results are 42 for and 15 against (total 57) for the secondary vote to
remove PHP's short
On Thu, 11 Apr 2019 at 12:14, Peter Cowburn wrote:
>
>
> On Wed, 10 Apr 2019 at 11:44, G. P. B. wrote:
>
>> Hello Internals,
>>
>> As there have been no further comments the voting for my RFC [1] to
>> deprecate PHP's
>> short open tags has started and
Hello Internals,
As there have been no further comments the voting for my RFC [1] to
deprecate PHP's
short open tags has started and will run for two (2) weeks.
Best regards
George P. Banyard
[1] https://wiki.php.net/rfc/deprecate_php_short_tags
Hello Internals,
Slightly later than expected but I will put the RFC to voting tomorrow if
no other discussion arises.
Also did some slight improvement to the RFC by adding a link to
PHP-CS-FIXER which can automatically
convert PHP's short open tags to the standard one and also added a Feedback
On Fri, 5 Apr 2019 at 19:52, Sara Golemon wrote:
> I was originally planning to just do this since I thought it'd be
> non-controversial, but while implementing I discovered some gotchas, so I'm
> putting it to the group for discussion. Please give attention to the
> "Backward Incompatible
On Fri, 5 Apr 2019, 09:26 Benjamin Coutu, wrote:
> Hello,
>
> I was surprised to find out that equality checks on zend_string do not
> take advantage of the fact that in many cases we have a hash key available
> that can be utilized in a quick bailout path without having to resort to a
> costly
Hello,
I don't really see the point of it as you self said this wouldn't add a
runtime check, so in what is it different to a comment?
More so reusing ! for this will, in my opinion, just lead to confusion as
people will think it negates the function, this is what
I would expect it to do at first
On Mon, 25 Mar 2019 at 20:42, Andrey Andreev wrote:
> Hi,
>
> On Mon, Mar 25, 2019 at 8:02 PM G. P. B. wrote:
> >
> > On Mon, 25 Mar 2019 at 16:38, Andrey Andreev wrote:
> >>
> >> OK, so why not flip it and make it always available instead? I'm a
On Wed, 27 Mar 2019 at 14:30, Benjamin Morel
wrote:
> > It is a well-known feature that you can work with such data without
> previously converting it explicitly to some number type.
>
> I'm not requesting to change this: if you're doing string("3.5") + int(7),
> you should still get
Seems like the discussion is split between this thread and the previous one.
This is maybe due to me not linking the RFC announcement email in the RFC
immediately and I apologize for this inconvenience.
I will try to answer to most things within the announcement thread. If I
missed someone could
Hello internals,
I would like to start the discussion about the deprecation of PHP's short
open tags:
https://wiki.php.net/rfc/deprecate_php_short_tags
As this is my first RFC all feedback is welcome.
However, due to the nature of the RFC and it being self-contained, the
planned date to
On Sat, 16 Mar 2019 at 03:44, Kenneth Ellis McCall
wrote:
> G. P. B. wrote:
> > currently going through the PHP doc to remove mentions of PHP 4
> > and stumbled upon the short_open_tag ini directive [1] which only affects
> > the availability of ` > From my unders
On Fri, 15 Mar 2019 at 17:03, Rowan Collins wrote:
> On Fri, 15 Mar 2019 at 15:56, G. P. B. wrote:
>
> > However, I'm not sure of the behavior if someone sets this behavior
> within
> > a file/class
> > does this only affect this specific instance or is it globally?
&
Just gonna do general reply instead of pointing at specific points.
But as it has been pointed out using short tags makes the code less
portable,
which IMO isn't ideal.
I personally don't tinker with INI settings withing PHP with `ini_set` as
IMHO if you
need to change them it should be done in
On Thu, 14 Mar 2019 at 18:20, Josh Di Fabio wrote:
> On Thu, Mar 14, 2019 at 3:49 PM Rowan Collins
> wrote:
> >
> > Is it really that important to save two key strokes per closure?
> >
>
> I'd say that the (probably overwhelming) majority of arrow functions
> have a single parameter and, in
On Tue, 12 Mar 2019 at 14:43, Christoph M. Becker wrote:
> On 12.03.2019 at 14:27, G. P. B. wrote:
>
> > I was more going along the lines of removing short tags altogether with
> the
> > ini setting as they are not available out of the box except if you use a
> > spec
I was more going along the lines of removing short tags altogether with the
ini setting as they are not available out of the box except if you use a
special compile flag. However, I didn't know they were used with template
engines but wouldn't they just use `
Hello internals,
I'm currently going through the PHP doc to remove mentions of PHP 4
and stumbled upon the short_open_tag ini directive [1] which only affects
the availability of `From my understanding, the `https://secure.php.net/manual/en/ini.core.php#ini.short-open-tag
On Sun, 10 Mar 2019 at 22:45, Larry Garfield wrote:
> Hello, peoples. I know it's been discussed once or twice before on the
> list, many years ago, but not recently. I therefore feel OK putting forth
> the following draft proposal for Comprehensions, aka "compact generators",
> in PHP:
>
>
On Sun, 3 Mar 2019 at 22:43, G. P. B. wrote:
> On Sun, 3 Mar 2019 at 22:24, Ryan Jentzsch
> wrote:
>
>> With semantic versioning b/c is allowed. For example version 8.0.0 vs
>> 7.x.x
>> -- version 8.0.0 could include major breaking changes (since it is a maj
On Tue, 26 Feb 2019 at 13:27, Nikita Popov wrote:
> Hi internals,
>
> I think it is well known that == in PHP is a pretty big footgun. It doesn't
> have to be. I think that type juggling comparisons in a language like PHP
> have some merit, it's just that the particular semantics of == in PHP
301 - 343 of 343 matches
Mail list logo
