Thank you all for your input.
I understand that I should be more active on the mailing list to get some
history. I think that is reasonable, but I don’t see why that is important.
I’m not applying based on my C skills, knowledge of processes or my
previous technical arguments. So, I can only
> Sounds like we need an RFC to make it clearer how voting karma for the
> RFC process will be granted in the future.
Yes, I agree. I would love to join that team, which is going to
prepare this RFC. Plus, I have shared some of the ideas in the
previous message.
Best
Hamza
On 7/19/21, Andreas
Hi Craig Francis,
> As an aside, only 4 of 23 'no' voters provided any comment as to why they
> voted that way on the mailing list, which I feel undermines the point of
> the Request For Comment process, with an additional 5 responding personally
> off-list after prompting. This makes it harder
> Currently there are people with voting permissions that do vote, yet do
not
interact with RFCs or the mailing list.
it does not help that depending on how you get the mailing list (like me,
in digest form) its almost impossible to actually chime in. just to reply
to this i have done about 13
On Mon, 5 Jul 2021 at 19:14, Craig Francis wrote:
> Hi Internals,
> I have opened voting on https://wiki.php.net/rfc/is_literal for the
> is-literal function.
>
This RFC has been rejected; with 10 votes in favour, and 23 against.
I'd like to thank everyone who has been involved in this
On Mon, 19 Jul 2021 at 18:26, Guilliam Xavier
wrote:
> On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas
> wrote:
>
> >
> > https://github.com/php/php-src/pull/7259
> >
>
> Great! Thanks! Interesting how it works out-of-the-box with just this
> addition in Zend/zend_language_parser.y:
>
> ```diff
On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas
wrote:
>
> https://github.com/php/php-src/pull/7259
>
Great! Thanks! Interesting how it works out-of-the-box with just this
addition in Zend/zend_language_parser.y:
```diff
type_expr:
type { $$ = $1; }
| '?' type { $$ = $2; $$->attr |=
On Mon, 19 Jul 2021 at 16:15, Bruce Weirdan wrote:
>
> On Mon, Jul 19, 2021 at 6:09 PM Dan Ackroyd wrote:
>
> > Prediction number 2: Having a null type in the language will happen
> > before PHP 9, which will enable people to have many bike-shedding
> > discussions over ?Bar vs Bar|null.
>
>
On Mon, Jul 19, 2021 at 6:09 PM Dan Ackroyd wrote:
> Prediction number 2: Having a null type in the language will happen
> before PHP 9, which will enable people to have many bike-shedding
> discussions over ?Bar vs Bar|null.
Hasn't that already happened in 8.0? It seems to work [1]
[1]
nicolas-grekas wrote on the PR:
> ?X cannot be confused with
It confused me. A compiler might understand it, but as a human I have
trouble understanding it.
Trowski wrote:
> The syntax should be either ?(X) or (X)|null
Non-ambiguous syntax is much better than ambiguous syntax.
On Mon, 19 Jul
Hey All
Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
> On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov wrote:
>>
>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm
>> wrote:
>>
>>> Hey.
>>> I would like to get karma to be able to vote on RFCs. I understand that
>>> voting karma isn’t
On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov wrote:
>
> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm
> wrote:
>
> > Hey.
> > I would like to get karma to be able to vote on RFCs. I understand that
> > voting karma isn’t usually given out to people who write their first
> > mailing list entry.
>
On 19.07.21 11:21, azjezz wrote:
however, when `T` is an intersection between `X` and `T` ( `X` ), `X $x = null` becomes
`null|X $x = null`, which is a combination between union and intersection types, however, as
the RFC stats, currently combination between union and intersection types is not
> I want to bring your attention to a behavior that was mostly overlooked:
>>
>>1. it is not possible to use an intersection type with an argument that
>>defaults to null
>>2. it is not possible to use an intersection type with a nullable
>>property (nor to make it default to null)
On Mon, Jul 19, 2021 at 4:05 PM Larry Garfield
wrote:
>
> I can see the argument that "I need something with these two interfaces...
> or nothing" is a valid use case to care about. However, as Saif noted,
> this is a side effect of the inability to mix union and intersection types.
>
> So, my
On Mon, 19 Jul 2021 at 12:51, Guilliam Xavier
wrote:
> there was *indeed* an SQL injection vulnerability in that code.
Yep, you're right, there was an issue in there as well.
esc_like() also needs to use esc_sql() for the value to be added directly
to the SQL string.
By changing to
On Mon, Jul 19, 2021 at 10:41 AM Nicolas Grekas
wrote:
> Hi all,
>
> I want to bring your attention to a behavior that was mostly overlooked:
>
>1. it is not possible to use an intersection type with an argument that
>defaults to null
>2. it is not possible to use an intersection
On Mon, Jul 19, 2021, at 4:21 AM, azjezz wrote:
> Hello,
>
> I personally don't consider a bug, but an expected behavior.
>
> when writing:
>
> ```
> T $x = null
> ```
>
> it is the same as writing:
>
> ```
> T|null $x = null
> ```
>
> or
>
> ```
> ?T $x = null
> ```
>
> however, when `T`
Hello all,
Tobias wants to obtain a right that lets him represent the community
in the RFCs' approval. Tobias, as for the feature requests, you can
discuss and propose your own ideas. You can also obtain RFC karma to
propose your ideas and contribute to the language.
As for the people that are
Hello,
I personally don't consider a bug, but an expected behavior.
when writing:
```
T $x = null
```
it is the same as writing:
```
T|null $x = null
```
or
```
?T $x = null
```
however, when `T` is an intersection between `X` and `T` ( `X` ), `X $x =
null` becomes `null|X $x = null`,
On Fri, Jul 16, 2021 at 2:47 AM Craig Francis
wrote:
> Just another day, and another injection vulnerability (please patch):
>
> https://woocommerce.com/posts/critical-vulnerability-detected-july-2021/
>
> If only escaping wasn't being used, so user values did not get included in
> certain
Hi All,
Thanks for the feedback. I decided not to pursue this for PHP 8.1, but I
still think it is a good idea. As Nikita explained Sara's suggestion might
not work at all.
While it is trivially easy to abstract this function in userland the aim is
to clean up PHP. This wouldn't add new
Den man. 19. jul. 2021 kl. 13.14 skrev Lynn :
> Currently there are people with voting permissions that do vote, yet do not
> interact with RFCs or the mailing list. Regardless of the reasons one may
> have for wanting to vote, the requirements given should be applied equally if
> this is the
>
> I know I’m not a “project leader” for any of the handful large PHP
> projects. I also know that I am far from the “top 1000 best developers”
> list. But I know that there are not many people (if any) that have a larger
> impact of user-land PHP right now.
>
> (I do acknowledge that there are
On Mon, Jul 19, 2021 at 11:47 AM Kalle Sommer Nielsen wrote:
> Why is it then fair to give them voting rights if they only contribute
> their vote but not words before hand? Why is it only possible to give
> feedback in terms of a +1 or -1 and not feedback in text form? Because
> if its only
Den man. 19. jul. 2021 kl. 12.11 skrev Lynn :
> I fully agree with this, as a developer I do not want to worry about low
> level php changes that do not directly impact me. Therefore I think that
> people who do get impacted by this (for example open-source package
> managers), at least get a
On Mon, Jul 19, 2021 at 10:33 AM Pierre wrote:
> Le 19/07/2021 à 10:11, Lynn a écrit :
> > A vast majority of proprietary code depends on open-source community
> > written by the community.
>
> All your arguments are good ones, even if in my position I don't agree
> with everything.
Thanks Nikita, that's good to know. I'm still familiarizing myself with the
source right now, so I apologize if this is something that commonly gets
spread as false information, I honestly was exploring the workings of
injection protection in the source after following this discussion, but
that's
Hi all,
I want to bring your attention to a behavior that was mostly overlooked:
1. it is not possible to use an intersection type with an argument that
defaults to null
2. it is not possible to use an intersection type with a nullable
property (nor to make it default to null)
3.
On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm
wrote:
> Hey.
> I would like to get karma to be able to vote on RFCs. I understand that
> voting karma isn’t usually given out to people who write their first
> mailing list entry.
>
> But I do believe I qualify as “Lead developers of PHP based
Le 19/07/2021 à 10:11, Lynn a écrit :
A vast majority of proprietary code depends on open-source community
written by the community.
All your arguments are good ones, even if in my position I don't agree
with everything. Nevertheless, I specifically don't agree with this one:
a lot of
On Mon, Jul 19, 2021 at 9:41 AM Pierre wrote:
> - For once, I'm writing PHP since PHP 3, and doing it professionally
> for more than 15 years, I wrote PHP code 8+ hours a day for the latest
> 15 years (more or less), I'm one of the many silent users for which each
> language feature change
Le 18/07/2021 à 22:46, Kalle Sommer Nielsen a écrit :
Hi
Den søn. 18. jul. 2021 kl. 21.47 skrev Tobias Nyholm :
Hey.
I would like to get karma to be able to vote on RFCs. I understand that voting
karma isn’t usually given out to people who write their first mailing list
entry.
I'm not
On Fri, Jul 16, 2021 at 6:04 PM Jordan LeDoux
wrote:
> I'm fairly certain that it is compatible, however I wanted to double check.
> Can LGPLv3 sources be included with the PHP source or is the PHP License
> incompatible?
>
In principle, it is compatible. We do bundle one LGPL 2.1 library
On Mon, Jul 19, 2021 at 5:56 AM Mike Schinkel wrote:
> I was just checking to see what the license was for PHP and this page[1]
> states:
>
> "PHP 4, PHP 5 and PHP 7 are distributed under the PHP License
> v3.01, copyright (c) the PHP Group."
>
> Can I assume that PHP 8 is also
On Sun, Jul 18, 2021 at 4:42 AM Jordan LeDoux
wrote:
> Related to the general topic of injection attacks, I was considering
> submitting a PR to change the default of PDO::ATTR_EMULUATE_PREPARES to
> FALSE, since this mistakenly can lead people to believe that using prepared
> statements with
36 matches
Mail list logo
