Hey Larry,
there's still ongoing discussion on the semantics, and mirroring implementation
defined semantics from the implementation into the RFC is not the way to go.
The RFC should discuss reasons of why semantics were chosen and the
implementation then be decided upon it. Describing it as
Just to clarify,
I said it didn't look like it could be a pure AST implementation, and that
it looks like you may need one additional instruction.
It does look that way to me - if only to throw a sensible error
specifically for pipes but also because it makes the imposition of specific
behaviour
I have opened the vote on the Pipe operator RFC:
https://wiki.php.net/rfc/pipe-operator-v2
The vote will close on 20 July.
--
Larry Garfield
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Mon, Jul 5, 2021, at 11:05 AM, Larry Garfield wrote:
> On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote:
> > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> > > Hi folks. Me again.
> > >
> > > A year ago, I posted an RFC for a pipe operator, |>, aka function
> > > concatenation.
My previous email had an ambiguous subject line. My apologies.
I've moved my RFC to the voting phase.
The proposal:
> Add a function that exposes the warning count of the most recent
statement for MySQL: $pdo->mysqlGetWarningCount(). It returns an int
straight from the MySQL driver. This fixes
Dear internals,
I didn't receive any more feedback on this RFC, therefore I would like to
start voting next week on the RFC as is.
Rationale:
- I would like to stick with a distinct curl.user_agent ini option to avoid
the BC break.
- Also using PHP_INI_ALL as the options visibility is matching
> Could you share some example of where you use it?
It looks like mt_rand() could be replaced by mt_rand(0, getrandmax()), but
that is not the case, mt_rand() with a specified range is an implementation
that generates random numbers until the desired value is obtained, which
may unintentionally
On 05-07-2021 20:14, Craig Francis wrote:
> Hi Internals,
>
> I have opened voting on https://wiki.php.net/rfc/is_literal for the
> is-literal function.
I am glad to see that the RFC eventually turned out as originally
proposed. It is simple and provides clear and strong guarantees about
the
Le mar. 6 juil. 2021 à 15:38, Nikita Popov a écrit :
> On Tue, Jul 6, 2021 at 2:30 PM Nicolas Grekas <
> nicolas.grekas+...@gmail.com> wrote:
>
>>
>> > > This is not 100% correct, you can have an attribte #[Foo(Foo::class)]
>>> and
>>> > > then calling ReflectionAttribute::getArguments would
> 1st
This is to avoid conflicts with the implementation in ext/standard. I don't
want to do it this way either, but I have to do it this way.
Since random in ext/standard does not use namespaces, I would like to
change the ext/standard side.
> 2nd
Although it goes back quite a long time, this
On Fri, Jul 2, 2021 at 3:58 PM Go Kudo wrote:
> > * The first bit is just clarification. After a cursory look at the
> implementation, my understanding is that the getInt(), shuffleArray() and
> shuffleString() APIs will always produce consistent results on 32-bit and
> 64-bit, as long as your
I was late in noticing the email. I'm sorry.
> I still feel we should find a better name for them.
This is based on Java's Random.nextInt(), which may indeed be confusing.
How about generateInt()?
> What's the range of its return? It's not clear in the RFC.
Currently, there is no way to
Le 26/06/2021 à 02:39, Go Kudo a écrit :
Hello Internals.
RFC has been reorganized for finalization.
https://wiki.php.net/rfc/rng_extension
1st I dislike the name "random_ext", why this "_ext" part ?
2nd why not following the standard process ?
1/ publish on pecl
2/ merge in php-src if
On Tue, Jul 6, 2021 at 2:30 PM Nicolas Grekas
wrote:
>
> > > This is not 100% correct, you can have an attribte #[Foo(Foo::class)]
>> and
>> > > then calling ReflectionAttribute::getArguments would also require to
>> > > resolve the type Foo. So this is not different than what could happen
>> >
On Tue, Jul 6, 2021 at 2:25 PM Jakob Givoni wrote:
> On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins
> wrote:
> >
> > Hi Mike,
> >
> >
> > > Instead I replied because your email strongly implied (stated?) that
> "deprecation required removal"
> >
> > I stand by that interpretation, which while
> > > This is not 100% correct, you can have an attribte #[Foo(Foo::class)]
> and
> > > then calling ReflectionAttribute::getArguments would also require to
> > > resolve the type Foo. So this is not different than what could happen
> > right
> > > now already.
> >
> >
> > Despite its name,
On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins wrote:
>
> Hi Mike,
>
>
> > Instead I replied because your email strongly implied (stated?) that
> > "deprecation required removal"
>
> I stand by that interpretation, which while not universal is very widely
> used, and I think is more useful than a
On Tue, Jul 6, 2021 at 12:58 PM Rowan Tommins
wrote:
> On 06/07/2021 11:31, Benjamin Eberlei wrote:
> > This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and
> > then calling ReflectionAttribute::getArguments would also require to
> > resolve the type Foo. So this is not
On 06/07/2021 11:31, Benjamin Eberlei wrote:
This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and
then calling ReflectionAttribute::getArguments would also require to
resolve the type Foo. So this is not different than what could happen right
now already.
Despite its
>
> I've opened voting on https://wiki.php.net/rfc/new_in_initializers. Voting
>> > will close on 2021-07-14.
>> >
>> > Note that relative to the original RFC, new support is limited to
>> parameter
>> > default values, attribute arguments, static variable initializers and
>> > global constant
Hi Daniel,
Please create a new email thread, with the tag [VOTE] in the subject along
with the
name of your RFC: "[VOTE] Add PDO function: mysqlGetWarningCount"
Threads with ambiguous titles like this one (subject is just "Vote!") are
likely to
be overlooked / ignored.
It would also have been
On Tue, Jul 6, 2021 at 9:31 AM Nicolas Grekas
wrote:
> Hi NIkita,
>
> I've opened voting on https://wiki.php.net/rfc/new_in_initializers. Voting
> > will close on 2021-07-14.
> >
> > Note that relative to the original RFC, new support is limited to
> parameter
> > default values, attribute
I've moved my RFC to the voting phase.
Voting will be open till 2020-07-21
https://wiki.php.net/rfc/pdo-mysql-get-warning-count
The pull request (with tests) is here:
https://github.com/php/php-src/pull/6677
Thanks for your time!
Daniel
On Tue, 6 Jul 2021 at 7:38 am, G. P. B. wrote:
> Although I think the idea of the feature is useful,
> I'm not so sure about the implementation.
> [...]
> Whereas using a function like concat_literal() which checks that the
> inputs are indeed literals provides immediate feedback that the type
>
On 06/07/2021 07:38, G. P. B. wrote:
This is I think the main issue with the current shape of the proposal.
This implementation will detect certain security issues, but finding the
root cause for them is going to be rather complicated, as the concatenation
operation is basically kicking the can
Hi Mike,
Instead I replied because your email strongly implied (stated?) that "deprecation
required removal"
I stand by that interpretation, which while not universal is very widely
used, and I think is more useful than a general hint at "bad practice".
You spend most of your e-mail
Hi NIkita,
I've opened voting on https://wiki.php.net/rfc/new_in_initializers. Voting
> will close on 2021-07-14.
>
> Note that relative to the original RFC, new support is limited to parameter
> default values, attribute arguments, static variable initializers and
> global constant initializers,
On Mon, 5 Jul 2021 at 20:15, Craig Francis wrote:
> Hi Internals,
>
> I have opened voting on https://wiki.php.net/rfc/is_literal for the
> is-literal function.
>
> The vote closes 2021-07-19
>
> The proposal is to add the function is_literal(), a simple way to identify
> if a string was written
28 matches
Mail list logo
