[PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void

Hey internals, I have closed the vote. The RFC was declined with 34 in favor and 22 against. Best regards, Benas On Fri, Jul 3, 2020, 12:12 AM Benas IML wrote: > Hey internals, > > I have opened the voting for the RFC, let's hope everything is going > to be smooth :). If you have any other

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, Jul 22, 2020 at 4:29 PM Sara Golemon wrote: > Citation Needed. > > The '@' token and the T_DOUBLE_AT token come from the lexer as distinct > values, where is the conflict? > > I'm not doubting that there is one, you're quite clever, but at the moment > you're stating facts not currently

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On 22-07-2020 18:51, Derick Rethans wrote: > This is something that STV is specifically designed to solve. You rank > in order by preference. And @@, <<>>, and #[] were all three options. > > In your example, these people would have marked @@ as first, <<>> as > second, and #[] as third. Ah,

[PHP-DEV] The @@ is terrible, are we sure we're OK with it?

However this syntax allows it to be used on 7.4 unlike any other.   This means that the initial transition of library functionality to it will be very smooth and will not require a separate implementation of polyfills for the syntax of doctrine annotations and attributes.   With any other

Re: [PHP-DEV] [RFC][VOTE] debug_backtrace alternative as an array of StackFrame objects

Hi internals, To answer the question of why I've voted no on this RFC, it's largely based on a uncertainty on what performance impact I'd expect and bc breaks. 1. There are memory leaks in the implementation PR, **so this can't be accurately benchmarked at the moment.** Improving performance

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, Jul 22, 2020 at 7:00 AM Derick Rethans wrote: > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > > Yes. Because we voted on it. Twice. > - It has the distinct possibility to cause further parsing issues, akin > to what ended up

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On 22-07-2020 16:45, Joe Ferguson wrote: > I would be happy to author an RFC on replacing @@ with #[] but based on > Larry's comments it sounds like the weighted voting already solved this > issue for us? We as internals just need to decide that @@ isn't a solution > and defer to the next ranked

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

On Wed, Jul 22, 2020 at 4:21 PM Christian Schneider wrote: > but not to arithmetic *operators* like 42 + "" because that doesn't > currently trigger E_WARNING AFAIK. > It does produce warning since PHP 7.1 : https://3v4l.org/4CV1E -- Best regards, Bruce Weirdan

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Hi! > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? I think it's not a very good idea, and <<>> was just fine, but a lot of folks apparently voted for it. Would be nice to see their opinion and how they answer your concerns. I'm not sure

Re: [PHP-DEV] [VOTE] Don't automatically unserialize Phar metadata outside getMetadata()

Hi internals, > As a minor suggestion: > > > Additionally, add an $allowed_classes parameter to both getMetadata() > > implementations, defaulting to the current behavior of allowing any classes > > (true). This will be passed to the call to unserialize() performed > > internally. > >

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Hi Derick, > Please, let's do the sensible and use the Rusty #[...] syntax. I'd probably re-vote for `<>` given the fact that `@@` may introduce similar parsing ambiguities in the future that may interfere with future language changes. (but those issues are not a certainty) I think that `#[`

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, July 22 2020 at 7:00 AM Derick Rethans wrote: > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > > - There are lots of grumbles, both on here, room 11, as well as in the > wider community

Re: [PHP-DEV] [VOTE] Don't automatically unserialize Phar metadata outside getMetadata()

Hi internals, > As a minor suggestion: > > > Additionally, add an $allowed_classes parameter to both getMetadata() > > implementations, defaulting to the current behavior of allowing any classes > > (true). This will be passed to the call to unserialize() performed > > internally. > >

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, 22 Jul 2020, Dik Takken wrote: > We do not know what the @@ voters would have chosen if the choice was > between << >> and #[]. In case the @@ voters have a preference for > <<>> the result could turn out differently. The only way to know is to > take another vote. This is something

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On 22/07/2020 17:43, Dik Takken wrote: That means we effectively disregard the preferences of the ones who voted for the @@ syntax. We do not know what the @@ voters would have chosen if the choice was between << >> and #[]. In case the @@ voters have a preference for << >> the result could turn

Re: [PHP-DEV] Changing default assertion mode to throw exceptions

Hi Den man. 13. jul. 2020 kl. 20.37 skrev Levi Morrison : > > Hello everyone, > > I'd like to change the default mode of assertion failures to throw. > The current default is to warn. In my opinion this is a bad strategy: > the engine asserted that something that is expected to be true is not, >

Re: [PHP-DEV] Changing default assertion mode to throw exceptions

On Wed, Jul 22, 2020 at 5:05 PM Gabriel Caruso wrote: > On Mon, 13 Jul 2020 at 19:37, Levi Morrison wrote: > > > Hello everyone, > > > > I'd like to change the default mode of assertion failures to throw. > > The current default is to warn. In my opinion this is a bad strategy: > > the engine

Re: [PHP-DEV] Changing default assertion mode to throw exceptions

On Mon, 13 Jul 2020 at 19:37, Levi Morrison wrote: > Hello everyone, > > I'd like to change the default mode of assertion failures to throw. > The current default is to warn. In my opinion this is a bad strategy: > the engine asserted that something that is expected to be true is not, > so

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Am 22.07.2020 um 16:45 schrieb Joe Ferguson: We as internals just need to decide that @@ isn't a solution and defer to the next ranked vote? I'd be the first one to +1. Makes sense to me; +1. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [RFC][VOTE] debug_backtrace alternative as an array of StackFrame objects

> Am 22.07.2020 um 09:10 schrieb Côme Chilliet > : > > Le Tue, 21 Jul 2020 13:52:39 +0200, > Michał Marcin Brzuchalski a écrit : >> Voting opened 2020-07-21 and closes 2020-08-04. >> >> Link to the RFC https://wiki.php.net/rfc/stack-frame-class#vote > > Hello, > > Can people voting no

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Hello, Internals, I would be happy to author an RFC on replacing @@ with #[] but based on Larry's comments it sounds like the weighted voting already solved this issue for us? We as internals just need to decide that @@ isn't a solution and defer to the next ranked vote? I'd be the first one to

Re: [PHP-DEV] [VOTE] Don't automatically unserialize Phar metadata outside getMetadata()

On Tue, Jul 21, 2020 at 3:37 PM tyson andre wrote: > Hi internals, > > I've started the vote on > https://wiki.php.net/rfc/phar_stop_autoloading_metadata > as announced earlier in https://externals.io/message/110871 > ([RFC] Don't automatically unserialize Phar metadata outside getMetadata()) >

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, 22 Jul 2020 at 14:00, Derick Rethans wrote: > Hi all, > > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > > - There are lots of grumbles, both on here, room 11, as well as in the > wider community

[PHP-DEV] Re: The @@ is terrible, are we sure we're OK with it?

On 22/07/2020 13:00, Derick Rethans wrote: I know we've voted twice on this already, but are we really sure that the @@ syntax is a good idea? No, no we are not. We've already found one gaping hole in it, we will likely find more. Why knowingly back ourselves into a corner when there are

Re[2]: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

I completely agree with this statement. Moreover, I had to write a full-fledged preprocessor in order to implement library functionality, suitable for both attributes and doctrine annotations (for version 7.4 and below).   Rust-like syntax (#[xxx]) is both visually pleasing and creates much

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

My suggestion is the tilde (~). Currently is used only as the bitwise NOT operator, but in this context seems to not have any problem. ~ Attribute1(~1) ~ Attribute2(...) function withAttribute() { ... } Or then we could use another more detailed syntax: <-- Attribute(...), ... --> ::

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

+1 El mié., 22 jul. 2020 a las 9:00, Derick Rethans () escribió: > Hi all, > > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > > - There are lots of grumbles, both on here, room 11, as well as in the > wider community

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Le Wed, 22 Jul 2020 13:00:10 +0100 (BST), Derick Rethans a écrit : > Please, let's do the sensible and use the Rusty #[...] syntax. This syntax is the one I liked the less in the proposed choices, given # is used for comments. Wouldn’t #[] cause more parsing issues than @@? What would be the

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

Am 16.07.2020 um 16:18 schrieb G. P. B. : > I've opened voting for the Saner Numeric strings RFC: > https://wiki.php.net/rfc/saner-numeric-strings Looking at the BC section I stumbled across > Code relying on the fact that '' (an empty string) evaluates to 0 for > arithmetic/bitwise operations.

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, Jul 22, 2020, at 7:49 AM, Brent Roose wrote: > Doesn't it make the most sense to re-vote the syntax? I'd consider the > previous vote to be invalid given the parsing issues that weren't > listed in the RFC. > > A re-vote seems the most fair: if the majority still prefers @@, then > so

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Doesn't it make the most sense to re-vote the syntax? I'd consider the previous vote to be invalid given the parsing issues that weren't listed in the RFC. A re-vote seems the most fair: if the majority still prefers @@, then so be it. Otherwise the syntax changes once again, before

Re: [PHP-DEV] Re: [RFC][Discussion] Objects can be declared falsifiable

On Tue, Jul 21, 2020, at 10:34 AM, Josh Bruce wrote: > Learning more everyday. This thread will be the “official thread” - > other related threads have been added to the RFC (including one from 11 > years ago): https://bit.ly/php-0002-rfc > > Created fork - with PR

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, 22 Jul 2020 at 13:39, Deleu wrote: > "Terrible" is the amount of humans having their lives taken by a pandemic. > This is at most slightly inconvenient for you. The aggressive tone in this > discussion is extremely unnecessary. > When the voted syntax is technically infeasible due to

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, Jul 22, 2020 at 2:40 PM Deleu wrote: > "Terrible" is the amount of humans having their lives taken by a pandemic. > This is at most slightly inconvenient for you. The aggressive tone in this > discussion is extremely unnecessary. > After the RFC was voted on for @@, objectively

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, Jul 22, 2020 at 2:39 PM Deleu wrote: > "Terrible" is the amount of humans having their lives taken by a pandemic. > This is at most slightly inconvenient for you. The aggressive tone in this > discussion is extremely unnecessary. > Hi, If you want to get nitpicky about the definition:

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Hi, On Wed, Jul 22, 2020 at 1:00 PM Derick Rethans wrote: > Hi all, > > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > I agree that @@ is really bad. Personally I'd prefer <<...>> but #[...] seems fine as well (although it's a minor BC

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

"Terrible" is the amount of humans having their lives taken by a pandemic. This is at most slightly inconvenient for you. The aggressive tone in this discussion is extremely unnecessary. On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans wrote: > Hi all, > > I know we've voted twice on this

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Hi Derick, śr., 22 lip 2020 o 14:00 Derick Rethans napisał(a): > Hi all, > > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > > - There are lots of grumbles, both on here, room 11, as well as in the > wider community

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Also, +1. I don't really care whether we switch back to `<<...>>` or `#[...]` but I think `@@` was a bad choice and thus, I think it would be a much more sensible decision to change the syntax again. At least for the sake of not running into new ambiguities and in order to stay more similar with

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Am 22.07.2020 um 14:00 schrieb Derick Rethans: Please, let's do the sensible and use the Rusty #[...] syntax. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans wrote: > Hi all, > > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > Pretty much clear that @@ is a bad choice - it was picked due to familiarity of some folks

[PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Hi all, I know we've voted twice on this already, but are we really sure that the @@ syntax is a good idea? - There are lots of grumbles, both on here, room 11, as well as in the wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/) - It has the distinct possibility to cause

Re: [PHP-DEV] Changing default assertion mode to throw exceptions

Hi Levi I personally almost never use assert, and actually assumed it would throw an error, so this sounds like a good change! Have you done research on how this would affect the top-1000-ish popular packages like Nikita does? Kind regards Brent > On 20 Jul 2020, at 15:48, Levi Morrison via

[PHP-DEV] Re: [RFC][DISCUSSION] Language Constructs Syntax Changes

Hello, I'm withdrawing the RFC since there is not much interest in it. Cheers, Michał niedz., 5 lip 2020 o 09:35 Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> napisał(a): > Hi internals, > > I realise we're tight to the deadline but from my calculations, > this RFC should fit with

Re: [PHP-DEV] [RFC][VOTE] debug_backtrace alternative as an array of StackFrame objects

Le Tue, 21 Jul 2020 13:52:39 +0200, Michał Marcin Brzuchalski a écrit : > Voting opened 2020-07-21 and closes 2020-08-04. > > Link to the RFC https://wiki.php.net/rfc/stack-frame-class#vote Hello, Can people voting no explain their vote? I did not see that much discussion against this prior to