Re: [PHP-DEV] Straw poll: Naming for `*any()` and `*all()` on iterables

[Craig Duncan]

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
needless typing

On Tue, 22 Dec 2020 at 17:08, Levi Morrison via internals <
internals@lists.php.net> wrote:

> I want to re-iterate my opinion on this discussion thread: anything with a
> prefix is a hard-no from me. Namespaces are literally designed for this
>

I don't understand why iter\any() and iter\all() don't appear in this straw
poll as they were in Nikita's original mail

Re: [PHP-DEV] [RFC] Deprecate passing null to non-nullable arguments of internal functions

[Craig Duncan]

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 values.
We saw a lot of code that passed undeclared variables to *count()*
and I can imagine people writing similar code with something like *strlen()*

Re: [PHP-DEV] max_input_vars trigger detection

[Craig Duncan]

>
> 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 {$max} input
variables are permitted");
}

Re: [PHP-DEV] Argument with default value

[Craig Duncan]

>
> 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, this has been proposed as RFC[1] quite a while ago, but has been
>> declined.
>>
>> [1] 
>>
>>
It was also briefly discussed last year:
https://externals.io/message/105123

Re: [PHP-DEV] Evolving PHP

[Craig Duncan]

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 propose a new RFC that
defines what future RFCs can be used for.

I'd also expect that RFC to include a proposal on how future "policy and
process" changes would be handled once RFCs had been limited.

>

Re: [PHP-DEV] Call for participation: Annotating internal function argument and return types

[Craig Duncan]

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?

[PHP-DEV] Using extract() with $this

[Craig Duncan]

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 over the top.
https://externals.io/message/93457

As reported in the below bug, extract() throws an exception when the
documentation suggests that it should be able to handle the scenario
(either by ignoring the request to overwrite *$this* or by creating a
prefixed version of it).
https://bugs.php.net/bug.php?id=77135

The only one I'm unsure of is the *IF_EXISTS* flags, as *$this* isn't in
the symbol table it's ignored even though technical *$this* does exist. But
as this is the current behaviour and doesn't cause an issue I thought for
BC it would be best to leave this behaviour alone.

Does anybody disagree with this change? Does it need an RFC?

[PHP-DEV] Parameter skipping

[Craig Duncan]

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 a few years ago: https://wiki.php.net/rfc/skipparams

I've re-read the previous discussion and it seems to me there were two
common arguments against:
* Just design better APIs
* Named parameters would be better

Nobody has been able to crack named parameters (and it doesn't seem likely
anytime soon), and as we've seen from the JSON example above it's not
always as simple as having better APIs, so I wanted to see whether people
would be willing to support the *default* keyword for optional parameters
now.

Thanks,
Craig

[PHP-DEV] Re: [VOTE] Making stdClass iterable

[Craig Duncan]

The RFC has failed with 7 votes in favour and 25 against.

Thanks again to everybody that got involved and voiced their opinions

Re: [PHP-DEV] [VOTE] Making stdClass iterable

[Craig Duncan]

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 same goals as this proposal.
The goal of this proposal is to make the language more consistent and less
surprising.
The *iterable* type accepts a plain array, but not an object that is used
to represent a plain array, that's surprising to me.

*stdClass* is "promoted" as part of the language, it's use is not advised
against anywhere in the manual, and it's the default response format for
*json_decode()*
To me, this class is presented as a first class citizen, but it works like
a second class one.

As it looks like my first approach to resolving this inconsistency is
likely to fail the vote, I'm considering a second approach now to update
the docs and "officially" deprecate/discourage usage of *stdClass*

[PHP-DEV] [VOTE] Making stdClass iterable

[Craig Duncan]

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 some ideas on a different implementation that I'll revisit if
the vote passes.

Voting will end in two weeks on 2019-02-18

Thanks to everybody that shared their opinion and raised concerns during
the discussion.

Craig

Re: [PHP-DEV] Making stdClass iterable

[Craig Duncan]

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 me in a pre-iterable world, but as we already
have an iterable type I don't understand why it shouldn't accept stdClass
as well as array.
What about an array is more iterable than a stdClass object?

Re: [PHP-DEV] Making stdClass iterable

[Craig Duncan]

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 assumes that anything Traversable will either be
> Iterator or IteratorAggregate. For userland code this is strictly enforced,
> but internal code can avoid this. However, the current exceptions to this
> are rather niche, while stdClass is somewhat commonly used.
>

That makes sense, if the RFC passes I'll pick up these implementation
points before proceeding, thanks

[PHP-DEV] Making stdClass iterable

[Craig Duncan]

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 function (json_decode) returning stdClass
we should make it easy/unsurprising to work with.

https://wiki.php.net/rfc/iterable-stdclass

Thanks,
Craig

Re: [PHP-DEV] [RFC] is_countable

[Craig Duncan]

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 successfully handled by 'count()',
internal/extension classes can implement a 'count_elements' handler and
ignore the interface.

I'd suggest that 'is_countable()' should be consistent with 'count()'.

Thanks,
Craig

Re: [PHP-DEV] json_encode() / json_decode() warnings

[Craig Duncan]

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
> desired functionality. :)


Hi Andrea, although that wouldn't break compatibility, it doesn't protect
new developers from using them dangerously.
That desired functionality is available in many userland libraries, I don't
think we gain much from adding it to core.
My aim is to make the core functions easier/safer to use out of the box.

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Craig Duncan]

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 issues, however that wouldn't help
with new developers picking up the `json_*` functions and using them
dangerously.
As pointed out in the original thread, there are plenty of wrappers that
provide this feature, the problem is that core functions have a huge gotcha.

If we introduced a new API then we'd need to deprecate the `json_*`
functions to make users aware, which I imagine would be the most
contentious thing suggested thus far

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Craig Duncan]

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't consider adding warnings as BC but in this case it
> is) for no benefit at all!
>
>
Hi Jakub, thanks for sharing you opinion.

While I agree there are BC concerns, I don't think it's accurate to say no
benefit at all. I regularly see new (and experienced) developers using
these functions without checking `json_last_error()`, trying to figure out
why the app is failing later without any warnings in the log can be very
difficult.

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Craig Duncan]

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 suppression operator.
>
> I certainly agree that the current situation is not good and that the json
> functions really ought to be throwing exceptions, but adding a warning now
> is only going to make this worse.
>
> Nikita
>
>

[PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Craig Duncan]

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, instead of requiring the developer to call
`json_last_error()` each time.

The functionality of `json_last_error()` and `json_last_error_msg()` are
unaffected and they can still be used in exactly the same way they are today

https://wiki.php.net/rfc/json_encode_decode_errors

Thanks,
Craig

Re: [PHP-DEV] json_encode() / json_decode() warnings

[Craig Duncan]

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 Exceptions by those that
do

[PHP-DEV] json_encode() / json_decode() warnings

[Craig Duncan]

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 _that_ unusual in PHP, however normally in these situations a
warning would be raised. But the JSON functions only raise warnings in a
couple of scenarios, most issues are completely silent.

I wanted to begin a discussion around changing this, so that warnings are
raised for any issues during `json_encode()` and `json_decode()`.

I have an implementation ready and I'm happy to draft an RFC if this
suggestion doesn't receive universal hatred.

Thanks for your time,
Craig

[PHP-DEV] Re: [RFC] [VOTE] Prevent number_format() from returning negative zero

[Craig Duncan]

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

[PHP-DEV] [RFC] [VOTE] Prevent number_format() from returning negative zero

[Craig Duncan]

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

Re: [PHP-DEV] [RFC] Prevent number_format() from returning negative zero

[Craig Duncan]

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

[PHP-DEV] [RFC] Prevent number_format() from returning negative zero

[Craig Duncan]

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 then it does display the
negative sign.
https://3v4l.org/k4roB

I believe these two operations should yield the same result. The RFC takes
the stance that the rounding version should be changed to never display -0,
but I'm open to hearing arguments to change number_format() to always
display the negative sign when it's working with a negative number.

https://wiki.php.net/rfc/number_format_negative_zero

Thanks,
Craig

[PHP-DEV] Re: number_format() = "-0.00"

[Craig Duncan]

On 25 November 2016 at 07:54, Craig Duncan <p...@duncanc.co.uk> 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

Re: [PHP-DEV] number_format() = "-0.00"

[Craig Duncan]

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 for number_format(), if that's what
> you meant.
>

Yeh, I'd imagine that's where most people will go looking when they
encounter this issue

Re: [PHP-DEV] number_format() = "-0.00"

[Craig Duncan]

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/wiki/Signed_zero
I'm not sure of its practical usage in PHP, I think most of our developers
would expect "0.00", but bring consistent with IEEE 754 makes sense.

Shall I add a note to the docs about this expected behaviour instead?

[PHP-DEV] number_format() = "-0.00"

[Craig Duncan]

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

[PHP-DEV] PR #1280 - Add an SplFileObject::getStream() method

[Craig Duncan]

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,
Craig

Re: [PHP-DEV] Countable Type Hint

[Craig Duncan]

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 and we shouldn't make it
> worse.
>

Nothing prevents it? As far as I'm aware there's no current way to type
hint Countable or array.
How would one add an interface that includes Countable and arrays?

Re: [PHP-DEV] Countable Type Hint

[Craig Duncan]

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, count($result));

The number of items in a countable can be established from the countable,
asking for it as a additional parameter doesn't make much sense to me

[PHP-DEV] Countable Type Hint

[Craig Duncan]

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) {
# ...
}
}

However I think this it is much more useful when combined with *iterable*,
maybe something like (arraylike = iterable && countable)

function handle_records(arraylike $result)
{
if (count($result) === 0) {
handle_empty();
return;
}

foreach ($result as $value) {
handle_value($value);
}
}

Does anybody have any thoughts on this?
Should I bring *countable* to RFC?
Should I bring *arraylike* to RFC?

Thanks,
Craig

Re: [PHP-DEV] How to detect classes with a count_elements handler in userland?

[Craig Duncan]

>
> 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

Re: [PHP-DEV] How to detect classes with a count_elements handler in userland?

[Craig Duncan]

> 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

[PHP-DEV] Re: [RFC] [VOTE] Counting of non-countable objects

[Craig Duncan]

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

Re: [PHP-DEV] [RFC] [VOTE] Counting of non-countable objects

[Craig Duncan]

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 Countable object."*

Under the "Return Values" section there is sentence about the current
implementation:
*"If the parameter is not an array or not an object with implemented
Countable interface, 1 will be returned. There is one exception, if
array_or_countable is NULL, 0 will be returned."*

I suggest we extend the "Return Values" section to say that a warning is
raised, but I don't see any need to change the manual beyond that.
Unless I have misunderstood you?

[PHP-DEV] [RFC] [VOTE] Counting of non-countable objects

[Craig Duncan]

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

Re: [PHP-DEV] [RFC] Counting of non-countable objects

[Craig Duncan]

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. Becker  wrote:
 is

> supposed to introduce a new E_WARNING in PHP 7.2.
>
> And yes, there is a (small) BC break, but even E_DEPRECATED might be
> regarded as such.
>


Thank you both for the feedback, I've gone with a warning now, I'll put the
RFC to vote in a few days

https://wiki.php.net/rfc/counting_non_countables

Re: [PHP-DEV] [RFC] Counting of non-countable objects

[Craig Duncan]

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 (instead of 0/1). But is the change of return value from 0/1 to false
> really sufficiently worthwhile to go with a deprecation first?
>
>
I don't feel strongly either way, as long as there's some clue that
something's not right.

Is there precedent for adding warnings in a minor? Would there be BC
concerns there?
I wouldn't want an RFC for a warning to fail when people would have voted
for a deprecation.



> In any case, if you want to go with deprecation, please specify what
> action this RFC implies for PHP 8.
>
>
Would it be acceptable for the RFC to state that this has no implications
for PHP 8, and is an indefinite deprecation?

Re: [PHP-DEV] [RFC] Counting of non-countable objects

[Craig Duncan]

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

Re: [PHP-DEV] [RFC] Counting of non-countable objects

[Craig Duncan]

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 sure whether other folk felt differently?

Re: [PHP-DEV] [RFC] Counting of non-countable objects

[Craig Duncan]

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 meaningless result.
>
> So, definitely +1 on a warning for all non-array non-Countable cases.
>
>
Ok, but if we're saying that count("string") === 1 is no longer a feature
then presumably it makes sense to deprecate in 7.2 and remove in 8.0?

Just raising a warning but still providing the feature feels weird to me

Re: [PHP-DEV] [RFC] Counting of non-countable objects

[Craig Duncan]

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 of the value.
>

I agree, and I'm happy to include scalars in the RFC if that's desired by
the majority.

Calling count() on a scalar is likely to cause a warning at some point, so
it's not as "hidden" as the iterator example:

if (count($string) > 0) {
foreach ($string as $value) {

[PHP-DEV] [RFC] Counting of non-countable objects

[Craig Duncan]

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 developers to the issue

https://wiki.php.net/rfc/counting_non_countables

Thanks,
Craig

Re: [PHP-DEV] Wiki RFC karma request: duncan3dc

[Craig Duncan]

On 2 October 2016 at 19:24, Craig Duncan <p...@duncanc.co.uk> wrote:

> On 4 January 2016 at 16:42, Craig Duncan <p...@duncanc.co.uk> 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 can create this?
>> >
>> > My wiki username is duncan3dc
>>
>> Is anybody available to grant me rfc karma for the wiki please?
>

Here's the draft RFC if that helps:
https://github.com/duncan3dc/php-src/blob/cdd79635bdd51648f1d2ce3627d56baa67f5190c/README.md

Re: [PHP-DEV] Wiki RFC karma request: duncan3dc

[Craig Duncan]

On 18 May 2016 at 14:53, Christoph Becker <cmbecke...@gmx.de> wrote:

> On 12.05.2016 at 21:31, Craig Duncan wrote:
>
> > On 4 January 2016 at 16:42, Craig Duncan <p...@duncanc.co.uk> 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 can create this?
> >>
> >> My wiki username is duncan3dc
> >
> > Is there a reason my request hasn't been responded to?
> > Is this not the correct way to request rfc karma?
>
> No, everything seems to be fine, so I'm pinging the admins, as this
> request apparently has been overlooked.
>
> --
> Christoph M. Becker
>
>
Is anybody available to grant me rfc karma for the wiki please?

Re: [PHP-DEV] Wiki RFC karma request: duncan3dc

[Craig Duncan]

On 4 January 2016 at 16:42, Craig Duncan <p...@duncanc.co.uk> 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 can create this?
>
> My wiki username is duncan3dc
>
> Thanks,
> Craig
>

Is there a reason my request hasn't been responded to?
Is this not the correct way to request rfc karma?

Thanks,
Craig

Re: [PHP-DEV] RFC about automatic template escaping

[Craig Duncan]

>
>
> 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

[PHP-DEV] Wiki RFC karma request: duncan3dc

[Craig Duncan]

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

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

[Craig Duncan]

On 2 March 2015 at 00:17, Niklas Keller m...@kelunik.com wrote:


 The proposed syntax has an issue:

 ?php

 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

https://github.com/php/php-src/pull/1133

Re: [PHP-DEV] Bugfest

[Craig Duncan (PHP)]

On 29 December 2014 at 07:59, Stanislav Malyshev smalys...@gmail.com
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. - or

 This would not require anything but basic knowledge of PHP and lots of
 time. If somebody wants to do it, arguably millions of people would
 benefit from it - since it would make real bus more prominent, thus
 making PHP devs more likely to fix them, thus improving PHP which is
 used by millions :) - so it is a great way to contribute. Any takers?


I'd be willing to spend some time on this. Presumably I'd need some
authorised access to the bug tracker?