[PHP-DEV] Re: 7.3 features in announcement

[Christoph M. Becker]

On 03.12.2018 at 19:37, Jakub Zelenka wrote:

> On Sun, Dec 2, 2018 at 10:50 PM Christoph M. Becker 
> wrote:
> 
>> Regarding the FPM logging changes: indeed, this seems to be quite an
>> improvement! :)  However, it seems there is no note in UPGRADING (which
>> is important for the migration guide in the manual) yet.  Could you
>> please add the missing note?
>
> That's a good point! Just added some extra info to the UPGRADING!

Thanks!

> I guess the release note about these changes should be a bit shorter. Maybe
> something like (feel free to edit it :) ):
> 
> Improved FPM logging with options to remove output decorations and
> extending limit on number of characters in the logged message.

The PHP 7.1.0[1] and 7.2.0[2] release announcements only had a lists of
linked captions, and I'm planning to follow suit.

[1] 
[2] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: 7.3 features in announcement

[Jakub Zelenka]

On Sun, Dec 2, 2018 at 10:50 PM Christoph M. Becker 
wrote:

> On 02.12.2018 at 21:24, Jakub Zelenka wrote:
>
> > I was wondering if we have got a final list of the top features that will
> > be listed in the announcement for the stable release.
> >
> > Not sure how it's usually selected but thought that it would be good to
> > list FPM logging changes that I have been working on and it's the main
> > improvement in FPM [1]. It's not probably that interesting for PHP devs
> but
> > it might be quite importants for DevOps who use FPM with Docker and want
> to
> > properly collect logs from containers. My current client will be updating
> > to 7.3 pretty soon just because of that.
> >
> > [1] https://github.com/php/php-src/pull/2458
>
> Thanks for bringing this up, Jakub!  To be honest, I haven't really
> thought about the release announcement before, so this is a fine reminder.
>
> Regarding the FPM logging changes: indeed, this seems to be quite an
> improvement! :)  However, it seems there is no note in UPGRADING (which
> is important for the migration guide in the manual) yet.  Could you
> please add the missing note?
>
>
That's a good point! Just added some extra info to the UPGRADING!

I guess the release note about these changes should be a bit shorter. Maybe
something like (feel free to edit it :) ):

Improved FPM logging with options to remove output decorations and
extending limit on number of characters in the logged message.

Cheers

Jakub

[PHP-DEV] Re: 7.3 features in announcement

[Tom Worster]

On 2 Dec 2018, at 17:50, Christoph M. Becker wrote:

> Regarding other prominent features, I think the “Flexible Heredoc and
> Nowdoc Syntaxes”[2] and the “PCRE2 migration”[3] should certainly be
> mentioned.  Also the MBString improvements[4], as well as the
> deprecations[5], and also the file related Windows improvements[6].
>
> I'm likely missing other important changes, and may overestimate some of
> those I've mentionened above.  I'm looking forward to suggestions!
>
> [2] 
> [3] 
> [4] 
> [5] 
> [6] 

Hi Christoph,

Do I read right that in 7.3 pcre gets UCD 10 while mbstring gets UCD 11?

And intl's UCD depends on the linked ICU library, right?

Tom

[PHP-DEV] Re: [RFC][Discuss] Covariant return- and contravariant parameter- types

[Levi Morrison]

On Mon, Nov 26, 2018 at 2:25 PM Levi Morrison  wrote:
>
> I am happy to announce my latest RFC, [Covariant Returns and
> Contravariant Parameters][1], is open for discussion. If you do not
> recognize those terms then hopefully the introduction coupled with the
> [examples][2] will help. Here is one snippet that demonstrates
> covariant return types:
>
>  interface Repository {
>   function fetch(int $id): ?Entity;
> }
>
> class UserFactory implements Repository {
>   function fetch(int $id): ?UserEntity {
> /* Since UserEntity is an Entity, this is now allowed */
> /* ... implementation ... */
>   }
> }
> ?>
>
> Covariant return types and contravariant parameter types are highly
> requested features; here are a few of the bug reports:
>
>   * https://bugs.php.net/bug.php?id=71825
>   * https://bugs.php.net/bug.php?id=72442
>   * https://bugs.php.net/bug.php?id=75385
>   * https://bugs.php.net/bug.php?id=75823
>
> There is a [preliminary implementation][3] that is available. It will
> not be rebased during discussion to allow people to check out the code
> and get updates without worrying about it breaking. The code quality
> can definitely be improved, and there are still a few todo comments in
> the code.
>
> Please do not discuss the items found in [Future Scope][4] as part of
> this thread, which includes discussing types such as `mixed`,
> `scalar`, `numeric`, etc.
>
> I look forward to your feedback, and especially with your
> experimentation with the implementation.
>
> Levi Morrison
>
>   [1]: https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
>   [2]: 
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#examples
>   [3]: https://github.com/php/php-src/compare/master...morrisonlevi:variance2
>   [4]: 
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#future_scope

Our existing engine doesn't always resolve "parent" at compile time
when possible. As part of this patch "parent" is resolved at
compile-time when possible and warnings and/or errors are emitted in
certain cases where there were none before. For instance, this would
only cause an error only if the method `C::m` were to be used:



This now emits an E_DEPRECATED warning when C is compiled. In 8.0 this
should be elevated to a COMPILE_ERROR.

The current edition of the RFC fails to mention this.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Don't silence fatal errors

[Zeev Suraski]

On Mon, Dec 3, 2018 at 12:51 AM Andrea Faulds  wrote:

> Hi Nikita,
>
> Nikita Popov wrote:
> > When the silencing operator @ is used, the intention is generally to
> > silence expected warnings or notices. However, it currently also silences
> > fatal errors. As fatal errors also abort request execution, the result
> will
> > often be a hard to debug white screen of death.
> >
> > The most recent occurrence which motivated me to write this mail is
> > https://bugs.php.net/bug.php?id=77205, but I've seen this play out
> multiple
> > times already.
> >
> > I would like to propose to change the behavior of @ to only silence
> > warnings, notices and other low-level diagnostics, but leave fatal errors
> > intake.
> It's always been bizarre to me that @ can silence fatal errors, which
> has no practical application and makes using @ to silence a lower-level
> error potentially hszardous if its targeted function can also produce a
> fatal error.
>

Well, it does have one practical application which I think we should pay
attention to if we are to change the behavior - in case of display_errors
being on (yes, nobody should have that in production, but that doesn't
change the fact that many do) - suddenly we would potentially be exposing
sensitive data to remote users - data that was previously explicitly
silenced and with this change we'd be breaking that contract.  This is not
an unlikely scenario.

OTOH I do see the value of being able to silence only non-critical
messages.  What if we do something along the lines of what somebody
proposed, and introduce another error level E_ERROR_WHILE_SILENCED or
something like that?  Folks who would want to will be able to turn it on,
and we can leave it out of E_ALL so that it would require explicit enabling.

Zeev

Re: [PHP-DEV] Re: 7.3 features in announcement

[Christoph M. Becker]

On 03.12.2018 at 12:08, Côme Chilliet:

> Le dimanche 2 décembre 2018, 23:50:54 CET Christoph M. Becker a écrit :
>
>> I'm likely missing other important changes, and may overestimate some of
>> those I've mentionened above.  I'm looking forward to suggestions!
> 
> It would be good if LDAP controls support in php-ldap is advertised, as it 
> also shows the module is maintained again.
> 
> Sadly I do not have a good link to give for this, I’m gonna try and fill the 
> documentation about this so that it can be linked to.

Thanks!  Indeed, PR #2640 looks like a considerable improvement.  Please
add a respective entry in UPGRADING (either self-explaining, or linking
to another document).

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: 7.3 features in announcement

[Côme Chilliet]

Le dimanche 2 décembre 2018, 23:50:54 CET Christoph M. Becker a écrit :
> I'm likely missing other important changes, and may overestimate some of
> those I've mentionened above.  I'm looking forward to suggestions!

It would be good if LDAP controls support in php-ldap is advertised, as it also 
shows the module is maintained again.

Sadly I do not have a good link to give for this, I’m gonna try and fill the 
documentation about this so that it can be linked to.

Côme

signature.asc
Description: This is a digitally signed message part.