Den 2021-06-18 kl. 16:08, skrev Nikita Popov:
On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield
wrote:
Hi folks. The vote for the Partial Function Application RFC is now open,
and will run until 30 June.
https://wiki.php.net/rfc/partial_function_application
Of particular note, a few people
>I would prefer an improved syntax for creation of anonymous objects. This
>is something which I have been annoyed with, myself.I'd like to see a
>simple way of creating anonymous objects with typed properties.
Another advantage arrays currently have over anonymous objects is destructuring
-
if
Hey folks,
On Sun, Jun 13, 2021 at 6:44 PM Marco Pivetta wrote:
> Hey folks,
>
> I'm posting here to introduce a new simplification, as well as
> quality-of-life-improving RFC:
>
> https://wiki.php.net/rfc/make-reflection-setaccessible-no-op
>
> The RFC is quite minimal, and proposes removing
Hi internals,
In every place where `key` is a valid php identifier
(e.g. can be used in PHP 8.0's named parameters),
I propose to allow `[key: expr]` to be used instead of `['key' => expr]`.
(including `list(key: expr)` and `array(key: expr)`
(This can be mixed anywhere with existing key/value
On 21.06.2021 at 17:53, Marco Pivetta wrote:
> On Sun, Jun 13, 2021 at 6:44 PM Marco Pivetta wrote:
>
>> I'm posting here to introduce a new simplification, as well as
>> quality-of-life-improving RFC:
>>
>> https://wiki.php.net/rfc/make-reflection-setaccessible-no-op
>>
>> The RFC is quite
Hi Tyson,
Interesting proposal, but I was going to reply with the exact same response
as Rowan. Why not use DTOs for such purposes? Arrays have rather limited
use cases. If you need to return multiple results from a function then you
should return an object with typed properties.
I don't like the
I'd like to note a couple of things ...
The behaviour of nullsafe and strict types being unspecified in the RFC
would allow us to solve those problems later.
The behaviour of strict types right now is objectively wrong, the partial
takes strictness from the application site, so as Nikita already
On 21/06/2021 17:54, tyson andre wrote:
In every place where `key` is a valid php identifier
(e.g. can be used in PHP 8.0's named parameters),
I propose to allow `[key: expr]` to be used instead of `['key' => expr]`.
This is an immediate "no" from me: it multiplies the ways to write the
same
On Mon, Jun 21, 2021, at 12:34 PM, Rowan Tommins wrote:
> On 21/06/2021 17:54, tyson andre wrote:
> > In every place where `key` is a valid php identifier
> > (e.g. can be used in PHP 8.0's named parameters),
> > I propose to allow `[key: expr]` to be used instead of `['key' => expr]`.
>
>
>
On Mon, Jun 21, 2021 at 2:25 PM Craig Francis wrote:
>
> On Sat, 12 Jun 2021 at 18:00, Craig Francis
> wrote:
>
> > I'd like to start the discussion on the is_literal() RFC:
> > https://wiki.php.net/rfc/is_literal
> >
>
>
> To recap,
>
> - We have chosen the name is_trusted(), based 18 votes
Hi Tyson,
Regardless of what others are saying, I personally like your RFC. The
reasons are following:
1. Because named keys are valid PHP names, they are resolved at the
parsing level. Thus, they will not be validated again and again.
Later, no constants are looked for.
2. At the runtime level,
Hi Mel Dafert,
> >I would prefer an improved syntax for creation of anonymous objects. This
> >is something which I have been annoyed with, myself.I'd like to see a
> >simple way of creating anonymous objects with typed properties.
>
> Another advantage arrays currently have over anonymous
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi, all!
This is a reminder from your friendly neighborhood 8.1 release managers
letting you know that we’ll release the first beta for PHP 8.1 in 30
days on 22 July.
This means FEATURE FREEZE for PHP 8.1 is on 20 July!
That’s right—we’ll close
On Tue, 22 Jun 2021 at 01:06, Derick Rethans wrote:
> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki wrote:
> >
> >The name "is_trusted" is misleading.
> >Literal is nothing but literal.
>
> I agree with this. The name is_trusted is going to be the same naming
> mistake as "safe mode" was.
Hi Rowan Tommins,
> This is an immediate "no" from me: it multiplies the ways to write the
> same thing from 2 to 4, in order to save a few bytes, in a few instances.
It's from 4 to 6 if you include single quoted strings vs double quoted strings.
If linters and automatic fixers were set up for a
On 21 June 2021 23:37:56 BST, Yasuo Ohgaki wrote:
>
>The name "is_trusted" is misleading.
>Literal is nothing but literal.
I agree with this. The name is_trusted is going to be the same naming mistake
as "safe mode" was. Developers will put their trust in it that it is 100%
guaranteed safe.
On Tue, 22 Jun 2021 at 12:18 am, Benjamin Morel
wrote:
> On Tue, 22 Jun 2021 at 01:06, Derick Rethans wrote:
>
>> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki wrote:
>> >
>> >The name "is_trusted" is misleading.
>> >Literal is nothing but literal.
>>
>> I agree with this. The name is_trusted is
On Fri, 18 Jun 2021 at 1:30 pm, Mike Schinkel wrote:
> For the avoidance of doubt can you confirm that this $sql would indeed be
> trusted?
>
> $ids = array_map( 'intval', $_GET['ids'] ?? [] );
>
> $where = implode( ',', $ids );
> $sql = 'SELECT * FROM foo WHERE id IN (' . $where . ')';
>
>
>
On Sat, 12 Jun 2021 at 18:00, Craig Francis
wrote:
> I'd like to start the discussion on the is_literal() RFC:
> https://wiki.php.net/rfc/is_literal
>
To recap,
- We have chosen the name is_trusted(), based 18 votes for, vs 3 against.
- Integers are now included, which will help adoption:
Hi and thanks for the clarification!
So if I get it right, by not addressing null safe calls and strict types
now we can address it later when we know a little bit more, which btw is
not the first time it's done. And the feature proposed requires a non
trivial implementation.
I think it
Den 2021-06-17 kl. 12:08, skrev Nikita Popov:
On Thu, Jun 17, 2021 at 11:53 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
Le Wed, 16 Jun 2021 10:16:37 +0200,
Nikita Popov a écrit :
1. Eagerly evaluate initializers on declaration. This is what I tried in
an
earlier revision
Am 21.06.2021 um 18:54 schrieb tyson andre :
> return [success: true, data: $data, cursor: $cursor];
> // is equivalent to the following, but shorter:
> return ['success' => true, 'data' => $data, 'cursor' => $cursor];
Just a little side-note: A while ago I proposed a 2-line-patch to allow :$foo
Hi Christian Schneider,
> > return [success: true, data: $data, cursor: $cursor];
> > // is equivalent to the following, but shorter:
> > return ['success' => true, 'data' => $data, 'cursor' => $cursor];
>
> Just a little side-note: A while ago I proposed a 2-line-patch to allow :$foo
> as a
Hi,
The name "is_trusted" is misleading.
Literal is nothing but literal.
Literals cannot always be trusted.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Tue, Jun 22, 2021 at 5:25 AM Craig Francis
wrote:
> On Sat, 12 Jun 2021 at 18:00, Craig Francis
> wrote:
>
> > I'd like to start the
On Mon, 21 Jun 2021 at 11:38 pm, Yasuo Ohgaki wrote:
> Hi,
>
> The name "is_trusted" is misleading.
> Literal is nothing but literal.
>
>
> eval('$var= '. $_GET['a'] );
>
> if (is_trusted($var)) echo $var;
> ?>
>
>
> Literals cannot always be trusted.
>
That’s explained in the RFC, under
25 matches
Mail list logo
