On Tue, 22 Dec 2020 at 16:21, Larry Garfield wrote:
> That's why I am OK with most options except `iterable_`, because that's a
> lot of needless typing.
>
Whether the prefix is iterable or iter or just i, I'll always be typing
iany and hitting enter, letting my IDE do the leg work, avoiding any
While making internal functions treat non-nullable types consistently with
userland is an absolute win,
I do wonder if it should be done simultaneously with changing some functions
to formally accept nulls.
I'm thinking back to all the pain caused when *count() *starting raising a
warning for null
>
> Although not particularly elegant, and it does require you to reject
requests that hit but don't exceed the limit, I've used this approach
before:
$max = ini_get("max_input_vars") - 1;
$check = count($_REQUEST);
if ($check > $max) {
throw new RequestException("Request is too large, only
>
> On Sat, 14 Mar 2020 at 15:53, Christoph M. Becker
> wrote:
>
>> On 14.03.2020 at 16:27, David Rodrigues wrote:
>>
>> > I would like to propose the idea of having a keyword that can be used to
>> > use the default value of a parameter, without necessarily having to know
>> > it.
>>
>> FWIW, thi
On Tue, 17 Sep 2019, 09:43 Christian Schneider,
wrote:
> Just because there are now policy and process RFCs does not mean we could
> take a step back and limit RFCs again.
>
I don't recall seeing anybody suggesting we can't do this. However the
established process to limit RFCs would be to prop
I'm happy to help.
Am I correct in thinking that the best way to locate outstanding ones is to
to search for any instances of *ZEND_BEGIN_ARG_INFO* or
*ZEND_BEGIN_ARG_INFO_EX*
in *.c files?
As once they've been converted they'll only appear in stub and header files?
Hi everyone,
I've just opened a pull request for some changes to *extract()* handling of
*$this*
https://github.com/php/php-src/pull/4133
I had a look through the original RFC discussion, and it looks like
extract() was brought up and then quickly handled, but it seems like the
handling was a bit
Hi all,
After starting to use https://wiki.php.net/rfc/json_throw_on_error in PHP
7.3 I've encountered the annoying issue of having to pass the $depth
parameter as 512 every time I want json_decode() to throw.
After doing this a few times I remembered the parameter skipping RFC that
Stas proposed
The RFC has failed with 7 votes in favour and 25 against.
Thanks again to everybody that got involved and voiced their opinions
On Tue, 5 Feb 2019 at 16:39, Levi Morrison wrote:
> I just wanted to pipe in to suggest an alternative approach to
> accomplish some of the same goals: an external PropertyIterator.
>
I believe Nikita suggested something similar, and while it would certainly
be useful it doesn't accomplish the s
Hi all,
Following the discussion it's now time to vote on whether we make the
stdClass iterable or not.
https://wiki.php.net/rfc/iterable-stdclass
Note that while there is an implementation available, the vote is only on
whether stdClass should fulfil the Traversable interface or not.
Nikita had
On Sat, 12 Jan 2019 at 20:13, Dan Ackroyd wrote:
> I think the correct long-term solution for this would be for us to
> revisit the union type RFC (https://wiki.php.net/rfc/union_types) and
> so be able to define a type like:
>
> type foreachable = object|iterable;
>
This argument makes sense to
On Mon, 14 Jan 2019 at 11:57, Nikita Popov wrote:
> Rather than implementing Traversable, I think it would be much better to
> implement IteratorAggregate and provide a proper getIterator()
> implementation. Objects that only implement Traversable are a PITA to work
> with and lots of code assume
Hi everybody
I'd like to propose a change to stdClass so that it can satisfy the
iterable parameter/return type.
Firstly I acknowledge that this isn't an ideal solution, but I think it
gets us to a better state than we're in today. It shouldn't be necessary,
but while we have such a common functi
Hi Gabriel,
I proposed a similar function at the time of introducing the warning, but
it doesn't look like I got around to creating an RFC for it:
https://github.com/php/php-src/pull/2206/files
During this work we realised that objects don't have to implement the
'\Countable' interface to be succ
On 29 July 2017 at 15:16, Andrea Faulds wrote:
> Could we not simply make it a flag? e.g.
>
> $bar = json_encode($foo, JSON_THROW_EXCEPTIONS);
> $baz = json_decode($bar, false, 512, JSON_THROW_EXCEPTIONS);
>
> That wouldn't break backwards-compatibility, but would still provide the
> desi
On 28 July 2017 at 12:46, Andrey Andreev wrote:
>
> This is a long shot, but here's an idea: an OOP API throwing exceptions.
>
> Would require more work both to implement and use, but it would surely
> be less error-prone and there'd be no BC break.
>
Hi Andrey, Yes that would resolve all BC iss
On 28 July 2017 at 12:36, Jakub Zelenka wrote:
>
> Also it would break a big amount of code because in case of converting
> errors to exceptions, you start getting a different exception so it would
> have to be handled. I would call the whole proposal just a big BC break
> (I'm aware that we don'
Hi Nikita,
Thanks for your input. Would you vote yes for throwing an exception?
On 28 July 2017 at 12:07, Nikita Popov wrote:
>
> Operations that are expected to fail should never generate warnings. We
> should not design functions such that their correct use requires the use of
> the error su
Hi internals.
As my initial thread about introducing warnings to the JSON functions was
not immediately flooded with disagreement I took the liberty of creating an
RFC for official discussion.
The proposal is to have `json_encode()` and `json_decode()` raise warnings
whenever a failure occurs, in
On 27 July 2017 at 16:57, Niklas Keller wrote:
> It should rather just throw exceptions. Warnings do not really allow error
> handling, they just allow error reporting.
>
>
Agreed, but I can't see Exceptions passing the vote. Warnings can be
silenced by those that don't care and converted to Exce
Hi internals,
When using `json_encode()` and `json_decode()` it is required that you
manually check for errors after every call, eg:
```php
$data = json_decode("false");
if (json_last_error() !== JSON_ERROR_NONE) {
throw new UnexpectedValueException(json_last_error_msg());
}
```
This isn't _
Voting has now closed and the RFC has passed with 14 votes for and 1
against.
https://wiki.php.net/rfc/number_format_negative_zero
Thanks to everybody that got involved.
I've submitted a PR for the implementation:
https://github.com/php/php-src/pull/2508
Thanks,
Craig
Hi everyone,
The RFC for making *number_format()* consistent when dealing with negative
zero is now in the voting phase.
Voting will be open for 2 weeks and will close at 0:00 UTC on Wednesday 3rd
May.
https://wiki.php.net/rfc/number_format_negative_zero
Thanks,
Craig
Just a reminder that I'll be putting the following RFC to vote in a few
days.
https://wiki.php.net/rfc/number_format_negative_zero
I presume the silence is due to there being no more objections, so I look
forward to the vote.
Thanks,
Craig
Hi internals.
Following a brief discussion on the behaviour of number_format() last year
I'd like to start discussion around an RFC to bring consistency to negative
zero.
When number_format() is passed -0 it doesn't display the negative sign,
however if it's passed something that rounds to -0 the
On 25 November 2016 at 07:54, Craig Duncan wrote:
> I've submit a PR (https://github.com/php/php-src/pull/2220) to fix a bug (
> https://bugs.php.net/bug.php?id=73581).
>
It sounds like opinions are divided on this, I'll draft an RFC including
the other instances Christoph mentioned
On 25 November 2016 at 08:58, Sherif Ramadan
wrote:
> I'm pretty sure this is covered by the language reference [
> http://php.net/language.types.float] as per precision of floating point
> numbers in PHP. Though I don't see much harm in adding a note with
> references there to the documentation
On 25 Nov 2016 08:11, "Rasmus Lerdorf" wrote:
>
> This doesn't seem like a bug to me. Our floating point is all IEEE 754
and as per IEEE 754 -0.00 is the correct and expected result here.
I've just read the link below and I'm inclined to agree on the technical
reasoning.
https://en.wikipedia.org/
Hi internals,
I've submit a PR (https://github.com/php/php-src/pull/2220) to fix a bug (
https://bugs.php.net/bug.php?id=73581).
Kalle suggested I run the change by here to see if there are any concerns
or feedback about merging this?
Thanks for your time,
Craig
Hey Internals,
Sorry if this isn't the correct thing to do, I was just hoping to raise
some awareness for a PR I opened last year:
https://github.com/php/php-src/pull/1280
It's a very simple and small addition, is it possible get it merged for
7.2, or do I need to raise an RFC for it?
Thanks,
Cr
On 19 November 2016 at 18:36, Stanislav Malyshev
wrote:
>
> > Should I bring *countable* to RFC?
>
> Nothing prevents one from having such interfaces or classes or traits if
> they need it. I don't see any need of adding more special cases into the
> language. Special cases are always bad design
On 17 November 2016 at 13:50, Josh Di Fabio wrote:
> What's the benefit of such an interface? Why not simply ask for `int
> $count` in your param list instead?
>
Using the example from my original email, it's a bit awkward to always have
to pass the count of a countable:
handle_records($result,
Hi everybody
Following on from the recent rfc for *count()* (
https://wiki.php.net/rfc/counting_non_countables) and the one for *iterable*
(https://wiki.php.net/rfc/iterable) it would be useful if there was a
`countable` type hint:
function foo(countable $thing)
{
if (count($thing) > 0) {
>
> Just to chime in ... can you split the PR into the RFC, and the new thing
> please.
>
Of course, that's done now: https://github.com/php/php-src/pull/2206
> How about just making those classes implement the interface instead?
Christoph pointed out that there may be classes in extensions that use
count_elements.
Also it would make userland code simpler:
is_countable($thing)
vs
is_array($thing) || $thing implements \Countable
Voting has now closed and the RFC has passed with 31 votes for and 0
against.
https://wiki.php.net/rfc/counting_non_countables
Thanks to everybody that got involved.
I've submitted a PR for the implementation:
https://github.com/php/php-src/pull/2185
Thanks,
Craig
Hi Dan,
On 23 October 2016 at 13:49, Dan Ackroyd wrote:
>
> When you update the manual, please can you explicitly what is allowed,
> rather than just saying what is not allowed as per the RFC text.
>
>
The manual already says what is allowed:
*"Parameters: array_or_countable An array or Countabl
Hi everyone,
The RFC for adding a warning when counting things that can't be counted is
now in the voting phase.
Voting will be open for 2 weeks and will close at 0:00 UTC on Friday 4th
November.
https://wiki.php.net/rfc/counting_non_countables
Thanks,
Craig
On 17 October 2016 at 21:57, Nikita Popov wrote:
> > I'm not sure I understand the motivation for throwing a deprecation
> notice
> > instead of a warning. In particular, what is the action that will be
> taken
> > here in the next major version?
>
On 18 October 2016 at 12:53, Christoph M. Becke
On 17 October 2016 at 21:57, Nikita Popov wrote:
>
>
> I'm not sure I understand the motivation for throwing a deprecation notice
> instead of a warning. In particular, what is the action that will be taken
> here in the next major version? I guess we would throw a warning and return
> false (inst
I've updated the RFC now to include count(null) which resolves the final
open question.
If there isn't any more feedback I'll open voting in a few days
https://wiki.php.net/rfc/counting_non_countables
Thanks,
Craig
I've updated the RFC now to take the deprecation route, and included
counting scalars:
https://wiki.php.net/rfc/counting_non_countables
The only remaining issue is what to do about handling *count(null)*
I think this should be deprecated too, but as it's the only case that
returns zero I wasn't s
On 4 October 2016 at 18:10, Nikita Popov wrote:
>
> A confounding factor is that count() has an alias sizeof() and for people
> coming from a C-like background it is quite natural to try to apply
> sizeof() to a string in order to get its length. This will silently "work",
> but return a meaningl
On 4 October 2016 at 11:17, Leigh wrote:
> You specifically mention that counting scalars is unaffected, is there
> a legitimate use-case for being able to use count() on them?
>
> I'd say using count() on a string or an int also constitutes a hidden
> bug, as it also always returns 1 regardless
Hi everybody
I'd like to propose the introduction of warning when counting objects that
can't be counted.
The default behaviour is to return 1 for these objects, which can be
misleading and hide bugs when attempting to count iterable objects (eg
Generators). Adding a warning would alert developer
On 2 October 2016 at 19:24, Craig Duncan wrote:
> On 4 January 2016 at 16:42, Craig Duncan wrote:
>>
>> > Hi,
>> >
>> > I'd like to create an RFC to change the behaviour of counting objects,
>> as
>> > discussed in the following pul
On 18 May 2016 at 14:53, Christoph Becker wrote:
> On 12.05.2016 at 21:31, Craig Duncan wrote:
>
> > On 4 January 2016 at 16:42, Craig Duncan wrote:
> >
> >> Hi,
> >>
> >> I'd like to create an RFC to change the behaviour of counting objects,
On 4 January 2016 at 16:42, Craig Duncan wrote:
> Hi,
>
> I'd like to create an RFC to change the behaviour of counting objects, as
> discussed in the following pull request:
> https://github.com/php/php-src/pull/1672
>
> Please can I be granted rfc karma so I ca
>
>
> Why do you assume that Latte parser is limited by regexp ability to parse
> HTML?
Because it is:
https://github.com/nette/latte/blob/19b759b550caaad75ca0dee5f0d85f9ffb59c845/src/Latte/Parser.php#L124
Hi,
I'd like to create an RFC to change the behaviour of counting objects, as
discussed in the following pull request:
https://github.com/php/php-src/pull/1672
Please can I be granted rfc karma so I can create this?
My wiki username is duncan3dc
Thanks,
Craig
On 2 March 2015 at 00:17, Niklas Keller wrote:
>
> The proposed syntax has an issue:
>
>
> function a () {
> echo yield * 3;
> }
>
> $a = a();
> $a->send(42);
>
> http://3v4l.org/n1sGb#v550
>
> This is currently valid PHP.
>
>
I've created a test for this, so we don't forget it in future
ht
On 29 December 2014 at 07:59, Stanislav Malyshev
wrote:
>
>
> We definitely need somebody triaging old bugs. The problem is it
> requires a real lot of time, and is mind-numbingly boring, so not many
> people do it. Many bugs are low quality - missing data, not having good
> descriptions, etc. - o
53 matches
Mail list logo
