[PHP-DEV] Deprecated partially supported callables: should is_callable() throw a deprecation notice ?

[Juliette Reinders Folmer]

L.s.,

I've just been looking in detail at the Partially Supported Callables 
deprecation RFC: 
https://wiki.php.net/rfc/deprecate_partially_supported_callables


The RFC explicitly excludes the `is_callable()` function and the 
`callable` type from throwing deprecation notices.


The |is_callable()| function and |callable| type remain side-effect 
free and do not throw a deprecation warning. They will continue to 
accept these callables until support is removed entirely. 


While I can fully support this for the `callable` type, I wonder if the 
decision to not throw a deprecation on use in `is_callable()` is the 
right one (though I understand the desire to keep it side-effect free).


Consider these code samples:

  function foo(callable $callback) {}
  foo('static::method');

This function call not throwing a deprecation is not problematic as in 
PHP 9.0 the function will start throwing a TypeError.


  if (is_callable('static::method')) {
  static::method();
  }

The second code sample, however, is problematic, as in PHP 9.0, the 
behaviour of this code will be silently reversed for those callbacks 
which would previously result in `is_callable()` returning true, which 
makes this a potentially dangerous change without deprecation notice.


Would anyone care to enlighten me as to whether this was given due 
consideration ?


Smile,
Juliette

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] Re: [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Juliette Reinders Folmer]

On 23-3-2022 14:46, Rowan Tommins wrote:

On 20/02/2022 18:55, Rowan Tommins wrote:


I would like to open discussion on an RFC to deprecate and later 
remove the functions utf8_encode() and utf8_decode()


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



Final chance for feedback on this RFC, as revised, before I put it to 
a vote.


There's been very little reaction on this thread, which I'm hoping 
means everyone's either planning to vote "Yes" or just doesn't care...


Regards,



While I agree the functions are often used incorrectly, what worries me 
about this RFC is that the only viable alternatives for these functions 
are in two optional extensions, which in practice will mean lots of 
projects will need to start polyfilling the old functions and/or start 
including a polyfill for one of the extensions, as they can not rely on 
those optional extensions being turned on.

Re: [PHP-DEV] Casing of acronyms in class and method names

[Juliette Reinders Folmer]

On 11-9-2023 1:57, Ben Ramsey wrote:
I agree. Using uppercase for the first letter in an acronym and 
lowercase for subsequent letters appears to be prevalent in many 
userland libraries, so it seems to be what users expect.


Since class names in PHP aren't case-sensitive, there should be no BC 
concerns for changing existing classes to fit this new casing (for 
Reflection, debug, and documentation purposes). That is, if we wanted 
to also update all existing class names in PHP that contain acronyms 
(e.g., DOMDocument -> DomDocument, SimpleXMLElement -> 
SimpleXmlElement, etc.).




This prevalence may stem from various CS checks enforcing/suggesting the 
naming like that based on their implementation/interpretation of 
CamelCaps name checks, often related to PSR4.


Along the same lines, I'm aware of CS-like tools enforcing the use of 
PHP native class names to be in the case as defined in PHP (mostly to 
prevent confusion when people search for more info on the class and 
such, even though it doesn't matter for the actual use).


With the above in mind, I wonder how much confusion/code churn renaming 
existing classes will cause and if that's worth it, especially as the 
suggested case for the PHP native class will likely be determined by the 
version on which the tooling is being run. I.e. tool being run on PHP 
8.2 suggest DOMDocument, tool being run on PHP 8.4 would flag 
DOMDocument and suggest DomDocument...


Smile,
Juliette

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Juliette Reinders Folmer]

On 15-9-2023 12:15, Dmitry Stogov wrote:

Hi,

After the code-review feedback, one of the most questionable decisions was
changed.
Instead of including IR Framework as a git submodule, now its part is
embedded into php-src.
This will complicate the IR/JIT development a bit, but will simplify things
for everyone else.

I'm going to merge https://github.com/php/php-src/pull/12079 into master
next week.
If someone likes to take a look before, please do it now.

After the merge, I don't plan to do active PHP-JIT development  for 1-2
months (I'll wait for problems, bugs, etc and work on general IR
improvements).
Then, in case of no major problems, I'm going to remove the old JIT
implementation and make a PHP-JIT code-cleanup pass.

Thanks. Dmitry.


On Mon, Sep 11, 2023 at 12:28 PM Dmitry Stogov 
wrote:


Hi internals,

I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.

It makes a base for future improvements and eliminates many low-level
details of the existing PHP JIT. Instead of supporting assembler code for
different CPUs, now PHP generates a single IR and passes it to a
PHP-independent JIT engine.

The old JIT implementation is going to be kept for a while.

Everybody are welcome to take a look over tne code
https://github.com/php/php-src/pull/12079

Thanks. Dmitry.



If merged to `master`, will that automatically mean that the next 
version of PHP will be PHP 9.0 ?


If so, would that warrant a separate discussion ? (whether there should 
still be a 8.4/8.5/8.6 or not)


Smile,
Juliette

Re: [PHP-DEV] Casing of acronyms in class and method names

[Juliette Reinders Folmer]

On 13-9-2023 17:48, Ben Ramsey wrote:

On 9/10/23 20:59, Juliette Reinders Folmer wrote:
With the above in mind, I wonder how much confusion/code churn 
renaming existing classes will cause and if that's worth it, 
especially as the suggested case for the PHP native class will likely 
be determined by the version on which the tooling is being run. I.e. 
tool being run on PHP 8.2 suggest DOMDocument, tool being run on PHP 
8.4 would flag DOMDocument and suggest DomDocument...



Since the names are case-insensitive, if the tools continue to 
enforce, for example, DOMDocument instead of DomDocument, would that 
cause problems if Reflection, var_dump, etc. began reporting the class 
name as DomDocument?


In other words, if the tools did not change, would there be any churn?


Tools wouldn't need to change to change their messaging on this.

In my experience, the case of the class as defined by PHP would be 
retrieved from PHP itself, so without the tooling changing, if PHP 
changes the case, the tooling will demand the new casing of the class 
names if run on a PHP version using the new casing. (and the old casing 
when run on an older PHP version)


Might be clearer via the below pseudo-code of typical logic used in 
tooling for checks like this:


$declared_classes = [];
if (empty($declared_classes)) {
$declared_classes = get_declared_classes();
$declared_classes = array_combine($declared_classes, 
$declared_classes);
$declared_classes = array_change_key_case($declared_classes, 
CASE_LOWER);

}



$seenClassLc = strtolower($seenClass);
if (isset($declared_classes[$seenClassLc]) && $seenClass !== 
$declared_classes[$seenClassLc]) {

// Throw error about the incorrect case being used.
}

Hope this clarifies my earlier comment.


And yes, I suspect changing the case will cause issues when name based 
comparisons are done in code as while tooling will use code like the 
above, in application code, names are often not compared in a 
case-insensitive manner.


Smile,
Juliette

Re: [PHP-DEV] Access property of object stored in a constant

[Juliette Reinders Folmer]

On 18-8-2023 17:27, Ilija Tovilo wrote:

Hi everyone

Since https://wiki.php.net/rfc/new_in_initializers we can store
objects in global constants. However, we may not actually read or
write to the properties of those objects without first fetching the
constant into a local variable.

const a = new stdClass;
a->b = 42; // Fatal error: Cannot use temporary expression in write context
$a = a;
$a->b = 42; // Works fine

This issue was reported twice, so it seems like this code is generally
expected to work.
https://github.com/php/php-src/issues/10497
https://github.com/php/php-src/issues/11781

I have created a patch here to add support for this syntax:
https://github.com/php/php-src/pull/11788

Since this is a language change I would like to ask for feedback
before merging. As always, if there are concerns I will create a small
RFC instead. I will also only merge this for 8.4, as feature freeze
for 8.3 has long passed.

Ilija



I totally understand that people are trying to do this, but this still 
very much feels like scope creep.


IIRC the new in initializers feature was _intended_ only for enums 
(which can't take properties). Now suddenly a "constant" would no longer 
be constant... In which case, what's the point of declaring it as a 
constant ?


Smile,
Juliette

Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throw a deprecation notice ?

[Juliette Reinders Folmer]

On 22-4-2022 3:02, php-internals_nos...@adviesenzo.nl wrote:


On 21-4-2022 21:56, Andreas Hennings wrote:

On Thu, 21 Apr 2022 at 11:18, Rowan Tommins  wrote:

On Wed, 20 Apr 2022 at 19:16, Claude Pache  wrote:


You make a very important claim in your bug report:


However, in real world, is_callable() is almost never given totally

arbitrary stuff

My concern is that we have no way of knowing whether this is true, and

whether there will always be a clear action for users who see the
deprecation notice.

In this case, there is always the possibility for them to use the error
suppression operator. That remains easy, and looks like a reasonable use
case of that operator.


The error suppression operator is a big blunt tool, and using it to squash
a deprecation notice would be an absolute last resort. Note that in
contrast to the strpos() case where both behaviours can be achieved with
*permanent* changes, the error suppression would only be a temporary
workaround for error logging, with no value in itself.




If we have to balance between addressing the verified issue of not
emitting deprecation notice for well-known and fairly frequent code
patterns, and addressing the potential and non-fatal issue of emitting too
much notices for totally unknown use cases, the choice should be
straightforward.


Again, this is true IF you are correct that one set of patterns is common
and the other is not, but so far I've not seen any attempt to find out
whether that's true. The idea of ignoring "unknown" use cases seems really
dangerous - like closing your eyes so you can't see the bad effects of what
you do. What we need to know is whether such use cases are *rare*, or
whether the people using them are just not subscribed to this list.

One starting point would be to find usages in the top 100 or 1000 packages
on Packagist usinghttps://github.com/nikic/popular-package-analysis  -
perhaps Juliette has already done that when testing their PHPCompatibility
sniff?

As a package author, you might not really know where the value is coming from.
A parameter will be declared as `@param mixed $callback_or_not`, if it
internally calls the`is_callable()` method.
And a static analysis tool will only see `mixed`, not "mixed, but if
it is a string, it does not start with 'static::', or if i's an array,
the first value is not 'static'.".

On the other hand, the value probably won't be completely arbitrary.
It might be coming from a discovery process that reads yml files or
annotations, or that calls some kind of hook in php. Or it is
generated with string concatenation.
Whatever it is, it is probably explicitly or implicitly hard-coded somewhere.

Here is a starting point for a search. But only for explicit calls.
https://sourcegraph.com/search?q=context:global+is_callable%5C%28%28%5C%5B%27%28static%7Cself%29%27%7C%27%28static%7Cself%29::.*%27%29%2C+lang:php=regexp



I appreciate it very much that Claude is trying to move the issue I 
raised forward.


Some responses to the discussion which has ensued:

1. In my opinion, the deprecation should only be shown when one of the 
deprecated syntaxes is passed either to a function with a `callable` 
type declaration or to `is_callable()`.
The deprecation notice should not be shown in any other circumstances, 
so an arbitrary invalid value being passed to `is_callable()` should 
still return `false` without deprecation notice.


2. While I do extensively test new PHPCompatibility sniffs, I have not 
run the WIP sniff against the top 1000 projects from Packagist, nor do 
I intend to or have the setup to do so.
I agree it would be a good idea to run a package analysis, but to be 
fair, in all honesty that should have been done for the original RFC, 
which was completely missing an impact analysis.


3. As for the pattern being common or not - the fact that I found it 
so easily in multiple random projects which I elected to test the 
sniff against, makes me believe the pattern is not _uncommon_.
I should also point out that all three of the projects which I 
highlighted as examples in my previous response are used extensively, 
the first two both have over 100 million downloads via Packagist, with 
the first being a dependency for PHPUnit.
The third doesn't show anywhere near as many downloads, but is a 
dependency of WordPress, which doesn't use Composer/Packagist for 
distribution, but is - as we're all aware - widely used.


In case anyone is looking for them - these were the examples I posted 
previously:


> Some examples:
> * 
https://github.com/symfony/service-contracts/blob/bc0a2247c72d29241b5a06fb60dc1c9d9acf2a3a/ServiceSubscriberTrait.php#L39 

> * 
https://github.com/mockery/mockery/blob/c10a5f6e06fc2470ab1822fa13fa2a7380f8fbac/library/Mockery/Mock.php#L960 

> * 
https://github.com/simplepie/simplepie/blob/dacf0ed495d2e8fb306e526ca3f2a846af78a7c9/tests/oldtests/absolutize/RFC3986.5.4/base.php#L13


Kind regards,
Juliette


P.S.: and yes, the issues in the first two examples 

[PHP-DEV] Re: Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

[Juliette Reinders Folmer]

On 18-3-2022 14:37, Christoph M. Becker wrote:

On 16.03.2022 at 06:52, Juliette Reinders Folmer wrote:

I've just been looking in detail at the Partially Supported Callables
deprecation RFC:
https://wiki.php.net/rfc/deprecate_partially_supported_callables
The RFC explicitly excludes the `is_callable()` function and the
`callable` type from throwing deprecation notices.

The |is_callable()| function and |callable| type remain side-effect
free and do not throw a deprecation warning. They will continue to
accept these callables until support is removed entirely.

While I can fully support this for the `callable` type, I wonder if the
decision to not throw a deprecation on use in `is_callable()` is the
right one (though I understand the desire to keep it side-effect free).
Consider these code samples:
   function foo(callable $callback) {}
   foo('static::method');
This function call not throwing a deprecation is not problematic as in
PHP 9.0 the function will start throwing a TypeError.
   if (is_callable('static::method')) {
   static::method();
   }
The second code sample, however, is problematic, as in PHP 9.0, the
behaviour of this code will be silently reversed for those callbacks
which would previously result in `is_callable()` returning true, which
makes this a potentially dangerous change without deprecation notice.
Would anyone care to enlighten me as to whether this was given due
consideration ?

Frankly, I don't know.  Apparently, there was almost no discussion about
that RFC.  Part of the reasoning to not raise E_DEPRECATED when calling
is_callable() was likely the typical use case
   $callable = …;
   if (is_callable($callable)) {
   call_user_func($callable);
   }
what would report the deprecation when actually calling the callable.
Not sure what to do regarding your given use case(s).
--
Christoph M. Becker


Unfortunately, those aren't the only places I see this happening and my 
example is not a stand-alone case either.


I came across the above code sample ( is_callable('static::method') / 
is_callable(['parent', __FUNCTION__]) with variable method calls) in a 
number of different packages when testing a (PHPCompatibility) sniff I 
am writing to detect the deprecation, so this code pattern looks to be 
relatively common.


Some examples:
* 
https://github.com/symfony/service-contracts/blob/bc0a2247c72d29241b5a06fb60dc1c9d9acf2a3a/ServiceSubscriberTrait.php#L39
* 
https://github.com/mockery/mockery/blob/c10a5f6e06fc2470ab1822fa13fa2a7380f8fbac/library/Mockery/Mock.php#L960
* 
https://github.com/simplepie/simplepie/blob/dacf0ed495d2e8fb306e526ca3f2a846af78a7c9/tests/oldtests/absolutize/RFC3986.5.4/base.php#L13

Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

[Juliette Reinders Folmer]

Hi Dan,

On 29-5-2022 17:34, Dan Ackroyd wrote:

Actually, I've just realised there is an error in the code in the RFC,
which might be based on a misconception caused by how terrible
callables are. In the code:
if (is_callable('static::methodName')) {
 // For valid callbacks, this call will be executed in PHP 8.x,
 // but will no longer execute in PHP 9.x.
 static::methodName();
}
The string based callable 'static::methodName' is not equivalent to
the syntax* based callable static::methodName().

...


This is actually not an error in the RFC, but an anonymized code sample 
based on real-life code patterns found in popular packages.


While the syntaxes are not technically equivalent, functionally, they 
yield the same result, which is why this code pattern is not uncommon.


It is exactly this type of code pattern - and the associated 
misconception leading to this code existing in real life code bases -, 
which started the initial discussion about the lack of deprecation 
notices for is_callable() and led to this RFC.



for the practical implications of fixing the deprecations,
there is no difference between the two.

People don't have to fix their code. Deprecations can sit there for as
long as the user likes. If a company decides that paying RedHat for
long term PHP 8.2 support, then they may choose to never fix these
deprecation warning and just silence them instead.
Which leads to a difference of, the deprecation notice when checking
with is_callable and using the callable can be suppressed reasonably
easily:
@is_callable('static::methodName')
@call_user_func('static::methodName', []);
And that's a reasonably sane** thing to do. But the deprecation notice
when passing callables around could happen across many pieces of code,
and there's not a good way of suppressing them, unless you just turn
off deprecation notices entirely.
With the deprecation notice where a user is checking, and a
deprecation notice where it is used, I don't see any value in extra
deprecation notices where the callable is being passed around.


IMO that's a false argument as deprecation notices are not intended for 
people who don't intend to upgrade their PHP version.


If there is no intention to upgrade to PHP 9.0, the much simpler 
solution would be to set `error_reporting` to `E_ALL & ~E_DEPRECATED`.
Alternatively, a custom error handling could be registered which filters 
out all, or only a selection of, deprecation notices.


Deprecation notices are for those people who _do_ want to upgrade to PHP 
9.0 once it comes out and want to prepare their code base to be ready.


And for those people, the `callable` type not throwing a deprecation 
notices means that for the "registered, but rarely called" callables, 
they will go from _nothing_ to a Fatal Error once PHP 9.0 comes round, 
which is exactly what this RFC tries to address.


Either way, I do agree that this potential objection should be heard, so 
I have added an extra section to the "Discussion" section of the RFC in 
which I have summarized our discussion (so far) about this: 
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices#these_additional_deprecation_notices_will_be_very_noisy



do you still feel that splitting the vote in two is the best way to go ?

Yes, due to the deprecation notices on type-checks when calling
functions have a higher pain-to-utility that in the is_callable check.

Fair enough, I will split the vote and have updated the RFC to show this.


I also like the deprecation notice on is_callable, as that notice will
be 'closer' to where the bad callable is coming from, so would be
easier to reason about. There's also a rare edge-cases where someone
has a callable that is only called in emergencies (like a disk running
out of space) and so might not have that happen for months. Having the
deprecation on is_callable would help those edge-cases a little.
Just pointing out, the same thing can happen with the `callable` type - 
a callable being registered for an emergency (like a disk running out of 
space), but not being called for months. This example edge case is not 
limited to `is_callable()`.


I hope the RFC update addresses your concerns sufficiently. If there are 
no further objections, I will open the vote.


Smile,
Juliette

[PHP-DEV] [VOTE] [RFC] Expand deprecation notice scope for partially supported callables

[Juliette Reinders Folmer]

L.S.,

I have opened the vote on the "Expand deprecation notice scope for 
partially supported callables" RFC: 
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices


The vote will run for two weeks and will close on June 14, 10:30 UTC.

The discussion threads about this RFC can be found here:
* https://externals.io/message/117720
* https://externals.io/message/117342

If anyone still wants to know a little more about the background of this 
RFC, you may want to have a listen to Derick's podcast about this RFC: 
https://phpinternals.news/101


Smile,
Juliette

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

[Juliette Reinders Folmer]

On 12-5-2022 18:54, Juliette Reinders Folmer wrote:
After the prior discussion about the same topic: 
https://externals.io/message/117342, I have created an RFC to expand 
the scope of the deprecation notices being thrown for the deprecated 
partially supported callables to include is_callable() and the 
callable type in PHP 8.2.


With this email I'm opening the two week discussion period for this 
RFC. All points raised in the prior discussion are already included in 
the RFC.


https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices 



I look forward to your feedback.



Seeing how there isn't any new discussions on this RFC and presuming 
that means that the previous discussion touched all concerns, I propose 
to open the vote on this RFC tomorrow.


RFC: 
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices


If anyone still wants to know a little more about the background, you 
may want to have a listen to Derick's podcast about this RFC: 
https://phpinternals.news/101


Smile,
Juliette

[PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

[Juliette Reinders Folmer]

After the prior discussion about the same topic: 
https://externals.io/message/117342, I have created an RFC to expand the 
scope of the deprecation notices being thrown for the deprecated 
partially supported callables to include is_callable() and the callable 
type in PHP 8.2.


With this email I'm opening the two week discussion period for this RFC. 
All points raised in the prior discussion are already included in the RFC.


https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices

I look forward to your feedback.

Smile,
Juliette

Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions

[Juliette Reinders Folmer]

On 16-5-2022 17:06, Andreas Leathley wrote:

Hello Internals,

After the first discussion about this topic
(https://externals.io/message/117608) I have created a preliminary
implementation and an RFC for making implicit boolean type coercions
more strict:

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

With this email I'm starting the two week discussion period. I welcome
any feedback on it and hope to further iron out the implementation if
needed. I mainly chose the route of introducing a deprecation notice
because it is in line with other RFCs that have similar goals (like the
Deprecate implicit non-integer-compatible float to int conversions RFC),
and it is fairly non-intrusive.


This RFC worries me as, in my opinion, it makes PHP's behaviour more 
surprising and inconsistent, not less.


It also raises the cognitive complexity for developers by yet another level.

1. It introduces a new interpretation of boolean type coercion, which is 
only applied against type declarations.
2. This new interpretation is not consistent with "normal" boolean type 
coercion, not consistent with strict types (no coercion) and also not 
consistent with what is considered a valid boolean value by the Filter 
extension.


While I agree that the current behaviour of PHP can hide bugs, I fear 
that even more bugs will be introduced when PHP contains yet a third 
form of coercion to boolean and the type coercion used is dependent on 
the context.


I see enough bugs on a daily basis which are/were introduced because 
people don't know the type coercion rules well enough. Adding yet 
another contextual layer to type coercion, makes things MORE complex, 
not less.


I fear this will only lead to more bugs, not less (because people new to 
PHP will learn the "type declaration" based boolean coercion rules and 
assume they apply everywhere).


I also fear that for code bases which do not (yet) use scalar type 
declarations, this will be one more argument not to introduce scalar 
type declarations (while they should).


I'd say that for this RFC to be acceptable it would need to apply to all 
implicit type coercions to boolean. However, the BC-break that would 
cause and the fall-out of this for non-greenfields codebases is just too 
huge, which, to me, makes this RFC a very strong no-no.


All in all, I largely agree with the flaws in this proposal as 
previously pointed out by Christian Schneider in the preliminary 
discussion. And I don't see those concerns addressed in the RFC (other 
than making it more explicit what the actual intended change is).


Smile,
Juliette

Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

[Juliette Reinders Folmer]

On 26-5-2022 20:23, Dan Ackroyd wrote:

Hey Julie,

On Thu, 26 May 2022 at 12:45, Juliette Reinders Folmer
 wrote:

I propose to open the vote on this RFC tomorrow.

Before you open the vote, please could you split the voting into two,
one for the is_callable, and one for the callable type check?

Rowan wrote in https://news-web.php.net/php.internals/117670:

is that passing "99 red balloons" to an "int"
parameter raised an E_NOTICE in PHP 7.x, so a "callable" parameter
raising an E_DEPRECATED should be fine.

There's one issue.

When "99 red balloons" is coerced to an int, that is done once, and
then any further int type check will pass. For callables, it's pretty
common to pass them down a stack of code, e.g. similar to:

function foo(callable $fn, $data)
{
 $fn($data);
}

function bar(callable $fn, $data)
{
 return foo($fn);
}

function quux(callable $fn, $data)
{
 return bar($fn, $data);
}


function main(array $data)
{
 $fn = get_callable_from_input();
 if (is_callable($fn) === false) {
// give some error.
 return;
 }

 quux($data);
}

As far as I understand it, this code would give a deprecation notice
for each call level, which seems quite undesirable. Particularly if
the callable is being used in a loop.

Also, without a patch it's hard to guess what performance impact this
would have. I doubt it would be huge, but it probably wouldn't be zero
either. Performance wouldn't matter for is_callable, as that is
typically only done once per callable, but callable type checks are
done continuously.

cheers
Dan
Ack


Hiya Dan,

I admit, I puzzled over this for a little and wanted to take the time to 
respond properly before opening the vote, so I'm delaying the start of 
the vote until beginning of the upcoming week.


In my first draft of the RFC I actually had two votes, but once it 
shaped up this was brought down to one vote.


Reason being, that for the practical implications of fixing the 
deprecations, there is no difference between the two.


In your example, you suggest a variable being passed between functions 
all using the `callable` type. The same can be encountered with 
functions without the `callable` type, but using manual defensive coding 
via `is_callable()` - typical example: a collection of callbacks being 
checked before being registered to a callback stack and being checked 
again before actually being called as the stack may have been 
manipulated from outside.


Yes, having each of those instances  throw a deprecation notice will be 
more noisy, especially if the same deprecated callback is used in a loop 
and yes, this will have a (small) performance impact while these 
callbacks aren't fixed yet, but the same *one* fix - at the point where 
the problematic callback is defined - will fix them all in one go, so 
the amount of fixes to be made does not change, but the chances of 
_identifying_ all the places were a fix is _needed_ is greatly improved.


In that sense, it is no different from the "99 red balloons" case when 
those issues are solved at the _source_ of the problem.
Patching the "99 red balloons" by applying `(int)` casts at the point 
the deprecation is thrown, will lead to a codebase full of type casts, 
while the underlying problem - the origin of the text string - is not 
addressed (and in the case of the callbacks, the origin is the only 
place they _can_ realistically be solved).


Considering the above, do you still feel that splitting the vote in two 
is the best way to go ?


Smile,
Juliette

Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

[Juliette Reinders Folmer]

On 12-5-2022 23:30, Claude Pache wrote:



Le 12 mai 2022 à 23:11, Larry Garfield  a écrit :

For the `callable` type declaration, I'm not opposed but is it redundant with 
the existing deprecation?  When would you pass a callable to something and not 
end up calling it anyway, which would trigger the existing deprecation?  
(Meaning in practice you'd always get 2 deprecations, which are not necessarily 
better than one.)

Although such a callable is probably intended to be called at some point, it is 
not necessarily called immediately, and it may be easier to track the source of 
it when you trigger the deprecation earlier. Example:

```php
public function registerErrorHandler(callable $onerror) {
 $this->onError[] = $onerror;
}
```

(Of course, this argument also holds for `is_callable()`.)

—Claude


Exactly as Claude says and to quote the RFC:

> While it will be common to use the partially supported callable in a 
callback function call within the function with the type declaration, 
this may not always be the case, especially in frameworks where 
callbacks can be registered to be executed later in a limited set of 
circumstances and those circumstances may not be met by default.


> Without a deprecation notice, those “/limited circumstances 
callbacks/” may not be discovered as needing updating in time for PHP 9.0.


Ref: 
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices#adding_a_deprecation_notice_for_callable


Smile,
Juliette

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] [VOTE] [RFC] Expand deprecation notice scope for partially supported callables

[Juliette Reinders Folmer]

On 31-5-2022 12:38, Juliette Reinders Folmer wrote:

L.S.,

I have opened the vote on the "Expand deprecation notice scope for 
partially supported callables" RFC: 
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices


The vote will run for two weeks and will close on June 14, 10:30 UTC.

The discussion threads about this RFC can be found here:
* https://externals.io/message/117720
* https://externals.io/message/117342

If anyone still wants to know a little more about the background of 
this RFC, you may want to have a listen to Derick's podcast about this 
RFC: https://phpinternals.news/101


Smile,
Juliette



Reminder: the vote on this RFC is still open for four more days. If you 
have voting rights and have an opinion on this, you have four more days 
to get your vote in.


Smile,
Juliette

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] [VOTE] [RFC] Expand deprecation notice scope for partially supported callables

[Juliette Reinders Folmer]

L.S.,


I have opened the vote on the "Expand deprecation notice scope for 
partially supported callables" RFC: 
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices


The vote will run for two weeks and will close on June 14, 10:30 UTC.

The discussion threads about this RFC can be found here:
* https://externals.io/message/117720
* https://externals.io/message/117342

If anyone still wants to know a little more about the background of 
this RFC, you may want to have a listen to Derick's podcast about this 
RFC: https://phpinternals.news/101


Smile,
Juliette


The vote for this RFC has now been closed.

The proposal to "throw a deprecation notice when is_callable() receives 
one of the deprecated partially supported callables" has been accepted 
unanimously with 28 votes in favour.


The proposal to "throw a deprecation notice when type verification on 
the callable type detects one of the deprecated partially supported 
callables" has also been accepted with 25 "yes" votes and 1 "no" vote.


Behind the scenes Rowan has worked hard on the actual implementation and 
has a draft ready. The final PR is expected to be pulled before feature 
freeze.


Thank you all for your support.

Smile,
Juliette

Re: [PHP-DEV] [VOTE] [RFC] Expand deprecation notice scope for partially supported callables

[Juliette Reinders Folmer]

L.S.,

I have opened the vote on the "Expand deprecation notice scope for 
partially supported callables" RFC: 
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices


The vote will run for two weeks and will close on June 14, 10:30 UTC.

The discussion threads about this RFC can be found here:
* https://externals.io/message/117720
* https://externals.io/message/117342

If anyone still wants to know a little more about the background of 
this RFC, you may want to have a listen to Derick's podcast about 
this RFC: https://phpinternals.news/101


Smile,
Juliette



Reminder: the vote on this RFC is still open for four more days. If 
you have voting rights and have an opinion on this, you have four more 
days to get your vote in.



Last call for action - the vote ends in less than 24 hours.


Smile,
Juliette

Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

[Juliette Reinders Folmer]

On 29-4-2022 16:36, Rowan Tommins wrote:

On 29/04/2022 03:04, Juliette Reinders Folmer wrote:
And that's basically exactly what I already did which led me to 
discover the patterns I posted about as they looked concerning 
(though I didn't use Nikic's tool, but the WIP PHPCompatibility 
sniff)...


I scanned a significant number of widely-used codebases and their 
dependencies and used the PHPCS `--report=code` view to see the code 
being flagged in context.
- Some of the things flagged were/are false positives (WIP sniff, 
still fine-tuning), which I could dismiss out of hand.
- Some of the things flagged is code which will start throwing 
deprecation notices (all good).
- Some code pattern flagged peaked my curiousity as they wouldn't 
throw a deprecation notice, but would lead to reversed behaviour... 
which is when I posted about this in the channel with the typical 
pattern I identified as dangerous without deprecation notice.



Great, that's all I wanted to hear, I'm not sure why it became such an 
argument.


Sorry for the confusion, I (mistakenly) thought it was clear from the 
start of the thread that I'd done my research.


I just didn't want to be having another conversation in a year's time 
with people whose code is raising deprecation notices they can't do 
anything about, because we made assumptions about how something's used 
without actually looking at it.




I'm not sure I understand what you mean...

As far as I understand it, if the deprecation notice is **only** thrown 
for the deprecated callables, the code can always be adjusted to use the 
recommended replacement code patterns as per the RFC to make the code 
cross-version compatible with PHP 9.0 (and prevent the deprecation notice).


So, `if ( is_callable( 'self::methodName' ) ) {}` could be adjusted to 
`if ( is_callable( self::class . '::methodName' ) ) {}`, or in the worst 
case if PHP < 5.5 would still need to be supported: `if ( is_callable( 
__CLASS__ . '::methodName' ) ) {}`.


No matter whether the code pattern is exotic (and may not have been 
considered), making the code cross-version compatible will generally 
still be desirable as the expected behaviour would otherwise still be 
reversed in PHP 9.0.

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

[Juliette Reinders Folmer]

On 1-5-2022 9:54, Rowan Tommins wrote:

On 1 May 2022 03:49:11 BST, Juliette Reinders Folmer 
 wrote:

As far as I understand it, if the deprecation notice is **only** thrown for the 
deprecated callables, the code can always be adjusted to use the recommended 
replacement code patterns as per the RFC to make the code cross-version 
compatible with PHP 9.0 (and prevent the deprecation notice).

My point is that returning false is not an error, so there may be code out 
there where no adjustment is actually needed, because either the old or new 
return value is fine.
As a very unlikely example that demonstrates the principle, imagine someone is 
randomly generating strings which look like callables but aren't. They use 
is_callable and look for a return value of false to confirm the generated 
string is not callable in the current environment. Since new strings are 
generated each time, they don't care how the same string will behave in a 
different version of PHP, so the deprecation notice is just a nuisance to them.
To repeat, I don't think that exact example is likely, but given the ingenuity 
of developers, I was worried there might be some other code pattern that put 
developers in that position.


I appreciate your concern.

Maybe this can ease your unease a little: in my investigations I did 
come across one (much less sophisticated) example of the kind of pattern 
you describe (in a method for Mockery, but with a hard-coded name of a 
method which shouldn't exist in a mocked class - the actual code has 
since been fixed, but this is what it was prior to the change: 
https://github.com/mockery/mockery/blob/472fa8ca4e55483d55ee1e73c963718c4393791d/library/Mockery/Mock.php#L939 
- and yes, this code did need changing anyway as otherwise the behaviour 
of the method would be reversed in PHP 9.0).


Having said that, that was ONE instance of an `is_callable()` check with 
a deliberately not existent method, versus dozens of instances of the 
code pattern which triggered this discussion.

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

[Juliette Reinders Folmer]

On 22-4-2022 8:47, Rowan Tommins wrote:

On 22 April 2022 02:02:58 BST, php-internals_nos...@adviesenzo.nl wrote:


I agree it would be a good idea to run a package analysis, but to be fair, in 
all honesty that should have been done for the original RFC, which was 
completely missing an impact analysis.

That's a fair point, but of course "somebody else should have done it already" 
isn't a good excuse not to do it now.



3. As for the pattern being common or not - the fact that I found it so easily 
in multiple random projects which I elected to test the sniff against, makes me 
believe the pattern is not _uncommon_.

Since there has been some misunderstanding, the usage I think we need to look for is where a deprecation notice would 
*not* be useful.  In other words, are there people using is_callable in such a way that even if a value like 
"parent::foo" changes from returning "true" to "false", there won't be anything that 
needs changing, because the code is equally "happy" with both return values?

I freely admit that I can't think of any such usage off the top of my head, but 
I wouldn't have thought of some of the examples already raised either.

If an actual search fails to find such usages, or provides evidence that it is 
very rare, then I am absolutely in favour of adding a deprecation notice.


Ah! So you're basically asking for the impossible. Search for a code 
pattern where a deprecation would not be useful, while noone has been 
able to come up with one.


In that case: search done. Nothing found. Let's get this fixed.

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

[Juliette Reinders Folmer]

On 28-4-2022 21:42, Rowan Tommins wrote:

On 28/04/2022 15:09, Juliette Reinders Folmer wrote:
Ah! So you're basically asking for the impossible. Search for a code 
pattern where a deprecation would not be useful, while noone has been 
able to come up with one. 



Not at all. I'm saying look at how different people use the function, 
and then see how the deprecation would affect them, without searching 
for any particular code pattern.


That's exactly what I did with my recent RFC, and I found it a very 
useful exercise in understanding the impact: 
https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode#usage


I would never have thought of some of the examples you showed in your 
earlier e-mail,  so I'm genuinely curious what other patterns it's 
used for.




And that's basically exactly what I already did which led me to discover 
the patterns I posted about as they looked concerning (though I didn't 
use Nikic's tool, but the WIP PHPCompatibility sniff)...


I scanned a significant number of widely-used codebases and their 
dependencies and used the PHPCS `--report=code` view to see the code 
being flagged in context.
- Some of the things flagged were/are false positives (WIP sniff, still 
fine-tuning), which I could dismiss out of hand.
- Some of the things flagged is code which will start throwing 
deprecation notices (all good).
- Some code pattern flagged peaked my curiousity as they wouldn't throw 
a deprecation notice, but would lead to reversed behaviour... which is 
when I posted about this in the channel with the typical pattern I 
identified as dangerous without deprecation notice.


Smile,
Juliette

Re: [PHP-DEV] Deprecated partially supportedcallables: should is_callable() throwa deprecation notice ?

[Juliette Reinders Folmer]

On 28-4-2022 17:00, Christoph M. Becker wrote:

On 28.04.2022 at 16:09, Juliette Reinders Folmer wrote:


On 22-4-2022 8:47, Rowan Tommins wrote:


On 22 April 2022 02:02:58 BST,php-internals_nos...@adviesenzo.nl  wrote:


I agree it would be a good idea to run a package analysis, but to be
fair, in all honesty that should have been done for the original RFC,
which was completely missing an impact analysis.

That's a fair point, but of course "somebody else should have done it
already" isn't a good excuse not to do it now.


3. As for the pattern being common or not - the fact that I found it
so easily in multiple random projects which I elected to test the
sniff against, makes me believe the pattern is not _uncommon_.

Since there has been some misunderstanding, the usage I think we need
to look for is where a deprecation notice would *not* be useful.  In
other words, are there people using is_callable in such a way that
even if a value like "parent::foo" changes from returning "true" to
"false", there won't be anything that needs changing, because the code
is equally "happy" with both return values?

I freely admit that I can't think of any such usage off the top of my
head, but I wouldn't have thought of some of the examples already
raised either.

If an actual search fails to find such usages, or provides evidence
that it is very rare, then I am absolutely in favour of adding a
deprecation notice.

Ah! So you're basically asking for the impossible. Search for a code
pattern where a deprecation would not be useful, while noone has been
able to come up with one.

In that case: search done. Nothing found. Let's get this fixed.

Isn't the following a *very* typical use case?

   if (is_callable($callback)) {
   call_user_func($callback);
   }

If $callback is something like "parent::foo", you get the deprecation
warning when you're actually calling the $callback.  An additional
deprecation warning for the is_callable() call would not be really
helpful in this case.
I do not agree with that assessment. With the huge amount of deprecation 
notices over the last few versions, it is pretty typical for people to 
focus *only* on the code flagged by the deprecation notice and not look 
at the wider context of the code.


So, like already happened in Symfony, the calls involving 
`call_user_func()` were fixed, but the deprecated usages in calls to 
`is_callable()` were not.



That said, I see the point in hinting at other usages (such as shown in
the OP), but I'm not really happy about a deprecation.  What about
providing a patch which warns about such usages without planning to
integrate that patch into php-src?  Similar like it was done with
<https://github.com/php/php-src/pull/3917>.


Eh... sorry, but I'm not sure what you mean. I can't imagine you mean 
creating a patch which is never intended to get merged ? That doesn't 
sound very useful.


Smile,
Juliette

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throw a deprecation notice ?

[Juliette Reinders Folmer]

On 2-5-2022 14:43, Rowan Tommins wrote:

On 02/05/2022 12:56, Alexandru Pătrănescu wrote:

The point is that this is not an usual deprecation, something that will
change to an error in the future.
In the end, it's just a change in behavior with no error before or 
after.

It does not fit the "deprecation".



That was my instinct too, but Juliette's analysis elsewhere on the 
thread has convinced me that it is very likely that anyone seeing this 
deprecation would want to change their code, rather than allowing it 
to change behaviour in 9.0.


Perhaps a reasonable comparison is the change in precedence of the 
concatenation operator 
[https://wiki.php.net/rfc/concatenation_precedence]. The expression 
("sum: " . $a + $b) is valid in PHP 7 and PHP 8, but has different 
results; PHP 7.4 included a deprecation notice because users would 
almost certainly want to choose which behaviour they wanted.


The difference in this case is that the code change probably won't 
happen in the same place as the is_callable() function call, but 
somewhere further up the stack. For instance, a framework function 
might accept arbitrary values and test them with is_callable; an 
application using that framework might pass "parent::foo", which will 
change behaviour in 9.0. It is the application's author who will 
benefit from the deprecation notice, so they can pass a different 
value whose behaviour isn't going to change.




I was going to mention the same example as the precedent ;-)

Either way, how will this get picked up now ? What are the next steps to 
put this thing in motion ?


(Note: please don't suggest for me to create a PR - I'm a PHP dev, not a 
C-dev)

[PHP-DEV] Request for wiki karma

[Juliette Reinders Folmer]

L.S.,

As per the progression of the discussion about the deprecated partially 
supported callable, a new RFC is needed to expand the scope of the 
deprecations. See: https://externals.io/message/117342


I'd like to request karma to create this RFC.

Username: jrf

Kind Regards,
Juliette

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] Additional small features for 8.2

[Juliette Reinders Folmer]

On 18-8-2022 15:46, Jakub Zelenka wrote:

Make libxml_set_external_entity_loader() return the previous loader
https://github.com/php/php-src/pull/7977


Based on the PR, this introduces a new function to PHP/the `libxml` 
extension. Doesn't that need an RFC ?


Note: I'm not opposed to the change as per the current implementation, 
just wondering if allowing this to go into PHP 8.2 without RFC is 
correct process-wise.



Add openssl_cipher_key_length function
https://github.com/php/php-src/pull/9368

Similar as the above, new function for the `openssl` extension.

I do think the two cases are different though as openssl is an optional 
extension, while libxml is enabled by default.


Smile,
Juliette

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Re: ***SPAM*** [PHP-DEV] Additional small features for 8.2

[Juliette Reinders Folmer]

On 18-8-2022 19:12, Jakub Zelenka wrote:

On Thu, Aug 18, 2022 at 5:11 PM Juliette Reinders Folmer <
php-internals_nos...@adviesenzo.nl> wrote:


On 18-8-2022 15:46, Jakub Zelenka wrote:

Make libxml_set_external_entity_loader() return the previous loader
https://github.com/php/php-src/pull/7977

Based on the PR, this introduces a new function to PHP/the `libxml`
extension. Doesn't that need an RFC ?

Note: I'm not opposed to the change as per the current implementation,
just wondering if allowing this to go into PHP 8.2 without RFC is
correct process-wise.


Add openssl_cipher_key_length function
https://github.com/php/php-src/pull/9368

Similar as the above, new function for the `openssl` extension.

I do think the two cases are different though as openssl is an optional
extension, while libxml is enabled by default.



If there are no objections, we have never required RFC for new functions
that are small and self contained. I'm also not aware that we would
differentiate between enabled by default and disabled by default ones . :)
If you follow php-src on GitHub, you will see that there are many addition
that don't go through the RFC process as there is no need for that.



Thank you for the clarification Jakub, the process is not always clear 
(to me).

Re: [PHP-DEV] [RFC] Asymmetric visibility

[Juliette Reinders Folmer]

On 5-8-2022 19:08, Larry Garfield wrote:

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: 
Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the same.



For what it's worth, here's my initial thoughts after reading the RFC:

1. In "Permitted visibility, it explicitly states that the "set" scope 
MUST be more restrictive than the "get" scope. However, no reason for 
this is provided. Please make the argumentation to support this choice 
explicit.


2. In "Interaction with __set" and "Relationship with readonly" the RFC 
states it wants to be consistent with the readonly behaviour, but that 
is a different keyword. IMHO, these modifiers should work independently 
of each other and are now improperly closely binded. If one wants 
readonly behaviour, use the `readonly` keyword.


3. I only see a hat-tip to the property accessors RFC regarding the 
chosen syntax.
I'd like to see a more extensive discussion and consideration of various 
possible syntaxes.

Some potential alternatives:
- "visibility(get) visibility(set) type $prop" - which makes it explicit 
what each visibility applies to
- "visibility(set: visibility) type $prop" - where it is clear that the 
"main" visibility is the default and anything within the brackets a 
deviation. This syntax would also more easily allow for expanding, like 
"visibility(set: visibility, unset: visibility) type $prop"


I understand the desire for parallelism with Swift, but I don't think 
that's a valid argument. The syntax should be right for PHP and if that 
would happen to overlap/sync with a syntax used elsewhere: great, but 
that's not an argument to only look at that syntax without a proper 
discussion and due consideration for alternatives.


4. While I see no mention of "multi-property declarations", I presume 
the visibility would apply to all ? I think it would be good to mention 
this explicitly in the RFC as well.
* By "multi-property declarations", I mean: `public string $type, 
$value = 'me', $somethingElse;


5. Are there tokenizer implications ? How will `set` (and possibly 
`get`) be tokenized ?


6. As this is something which can already be handled via magic methods, 
is there sufficient reason to make the language/engine more complicated 
to support this via a syntax ?


Overall, I mainly just see an idea in the RFC, but no justification for 
the need for it, let alone for any of the choices made.


Smile,
Juliette

Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2

[Juliette Reinders Folmer]

On 2-11-2022 18:46, Benjamin Morel wrote:

Hi internals,

It just came to my attention that there is a change of behaviour between
PHP 8.1 and 8.2 in the way iterable is decomposed, or not, into
Traversable|array when reflected:

```
function foo(): iterable {}
function bar(): stdClass|iterable {}

echo (new ReflectionFunction('foo'))->getReturnType(), PHP_EOL;
echo (new ReflectionFunction('bar'))->getReturnType(), PHP_EOL;
```

Output on PHP 8.1:

```
iterable
stdClass|iterable
```

Output on PHP 8.2:

```
iterable
stdClass|Traversable|array
```

Is this expected behaviour? Or should I file a bug? I'm particularly
surprised that it behaves this way on PHP 8.2 only in the presence of union
types.

Thank you,
Benjamin

That's a intentional behaviour change and related to this accepted PHP 
8.2 RFC: https://wiki.php.net/rfc/iterator_xyz_accept_array


Smile,
Juliette

Re: [PHP-DEV] Final anonymous classes

[Juliette Reinders Folmer]

On 24-4-2023 12:28, Daniil Gentili wrote:

Hi all,

I've submitted https://github.com/php/php-src/pull/11126 to add 
support for final anonymous classes, though as noted by iluuu1994, it 
would probably make more sense to just make all anonymous classes 
final by default, what do you think?


Daniil Gentili.



I always though anonymous class where `final` by nature. The fact that 
that hack to extend them works, seems iffy at best.


For what it's worth, I'd be in favour of making the default behaviour 
for anonymous classes `final` without the need to add a `final` keyword.


For those edge-cases which would be broken by that change, I wonder if 
support to opt-out could be added via an `#[AllowAliasing]` attribute ?

Re: [PHP-DEV] Array spread append

[Juliette Reinders Folmer]

On 6-4-2023 0:12, Vorisek, Michael wrote:

Hello,

I would like to open a discussion for 
https://github.com/php/php-src/issues/10791 .
[https://opengraph.githubassets.com/a23cb565cc8acac6a33ecab5d9ee68a46f046a1ffe215501673156e506695430/php/php-src/issues/10791]
Array spread append · Issue #10791 · 
php/php-src
Description Currently spread operator can be used for almost anything. But not for 
array append. I propose the following to be supported: 

I have the feeling I'm missing something, but how would this compare to 
array join (which is already available and is actually shorter than this) ?


$arr += $arr2;

Smile,
Juliette

[PHP-DEV] Unexpected behaviour when using Traits with final methods

[Juliette Reinders Folmer]

Hi all,

I'm running into something which peaked my curiousity due to its 
unexpected behaviour, so I'm writing to the list in the hopes of finding 
out whether this is by design, a bug or an oversight which should be 
fixed (via an RFC?).


> The precedence order is that members from the current class override 
Trait methods, which in turn override inherited methods.
Source: 
https://www.php.net/manual/en/language.oop5.traits.php#language.oop5.traits.precedence


If one would want to prevent the "current class" from being able to 
override a trait method, I would expect that the `final` keyword would 
be able to do this, just like it would when a method is inherited from a 
parent class.


Unfortunately, that does not seem to work and it appears that the 
current class can freely override final methods from a trait:


```
trait Foo {
final protected function bar() {
echo 'Foo';
}
}

class FooBar {
use Foo;

public function __construct() {
$this->bar();
}

protected function bar() {
echo 'FooBar';
}
}

new FooBar(); // Prints "FooBar".
```
https://3v4l.org/hlirb

Which brings me to my second point: in PHP 8.0 the use of the `final` 
keyword with `private` methods has been turned into a `warning` via this 
RFC: https://wiki.php.net/rfc/inheritance_private_methods


... but the "current class" has access to `private` methods inherited 
from a trait, so I would expect `final private` methods in traits to be 
exempt from that warning, but turns out that that will still throw the 
warning: https://3v4l.org/Vb0S2


Is there anyone who can shed some light on this behaviour ?

Smile,
Juliette

Re: [PHP-DEV] [RFC] Interface Default Methods

[Juliette Reinders Folmer]

On 15-6-2023 5:47, Levi Morrison via internals wrote:

Hello, PHP Internals,

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

This can be a useful tool for a few reasons:
  1. It can make implementing an interface easier when certain methods
can be implemented by other methods in the interface. For example, if
`Countable` had an `isEmpty(): bool` method, it could be implemented
by doing `$this->count() > 0`. Of course, if an implementation can be
more efficient, they are still free to implement it how they want.
  2. It can mitigate BC breaks in some cases. It's somewhat common for
authors to want to expand new methods onto existing interfaces over
time. Although this would still be a BC break, it moves it from a
massive change (every single implementor must add something, even if
it's a stub, or it will fail to compile) to a naming collision issue
only (only classes which already had a method of the same name will
fail to compile).

There is prior art for this feature in both Java and C#. There may be
other languages, but I was aware of at least these.

Note that the RFC links to a partial implementation. If there are two
or more interfaces with default methods of the same shape (name, args,
etc) and a class implements both interfaces and doesn't provide a
concrete implementation, which default implementation should be
chosen? There is a proposal for resolving this in some cases which is
modelled after Java's implementation, but it isn't implemented.

Thank you for your time. I look forward to productive feedback.

Levi Morrison



Hi Levi,

Thanks for the RFC. The usecase seems clear.

There are two things I'm missing on an initial read of the RFC.

> Adding a default implementation to an existing interface method will 
not break existing code, because every existing usage has a higher 
priority than the default.


A: How would this work if the existing method in the implementing class 
has a different function signature than the newly introduced method in 
the interface ?

There are two aspects to this:
1. What if the existing method has different parameters ?
2. What if the existing method has the same parameters, but 
different/incompatible parameter/return types ?


B: How does the ability to add default method implementations to an 
interface compare to providing an abstract class implementing the 
interface and providing the default method implementations ?


Smile,
Juliette

Re: [PHP-DEV] RFC [Discussion]: Closure self-reference

[Juliette Reinders Folmer]

On 3-6-2023 21:11, Dan Ackroyd wrote:

Hi internals,

I'm now opening the discussion for the Closure self-reference RFC:
https://wiki.php.net/rfc/closure_self_reference

This was previously discussed as a draft here:
https://externals.io/message/112216#112216

Thank-you to KapitanOczywisty for the implementation.

cheers
Dan
Ack



Hi Dan,

When I read the RFC, I keep wondering why new syntax is needed for this. 
Isn't this a solved problem with the solution being "use a named function" ?


Might I suggest to expand the RFC to answer all or at least some of the 
below questions ?
* Why is a recursive function call something which should be supported 
at the language level for closures ?
* Was the pre-existing syntax available to solve this - named functions 
- considered ?
* Why is using named functions not considered a valid solution by the 
RFC proposers ?


As for the syntax choice: it seems like the proposed choice is largely 
arbitrary and personal to the authors to go for a "languagesy" syntax.

* Was any research done on how frequently this is expected to be used ?
* If so, does that frequency justify the need for a change at the 
language level ?
* Was any research done to find out syntax preferences from anyone other 
than the authors ?
* Was the impact of introducing (yet another) syntax level change on 
static analysis tools considered ?
As a co-maintainer of a static analysis tool, I would have a strong 
preference for either `__CLOSURE__` or a static function on the Closure 
class as that would make the syntax "isolated" to this change, while an 
`as $fn` syntax change would mean that any analysis of the `as` keyword 
and a lot of analysis of variables will need to be adjusted to allow for 
this new syntax.
Not necessarily a reason to change the proposal, but possibly 
something to consider.


Either way, my two pennies for whatever they are worth.

Smile,
Juliette

[PHP-DEV] Updating the RFC list page

[Juliette Reinders Folmer]

RFC authors,

I just noticed that the PHP 8.3 "PDO driver specific sub-classes" RFC is 
still listed as "in voting". The "Deprecate functions with overloaded 
signatures" RFC is still listed as "pending implementation". As far as I 
can see, both have been accepted/merged and can be moved to 
"Implemented/PHP 8.3" (and updated with links to the implementation 
PRs/commits).


There may be more RFCs which may need to be moved to different sections 
on the page and/or get a status update.


May I ask the RFC authors to do so in the run up to PHP 8.3-RC ?

Smile,
Juliette

Re: [PHP-DEV] Updating the RFC list page

[Juliette Reinders Folmer]

On 6-8-2023 13:13, Juliette Reinders Folmer wrote:

RFC authors,

I just noticed that the PHP 8.3 "PDO driver specific sub-classes" RFC 
is still listed as "in voting". The "Deprecate functions with 
overloaded signatures" RFC is still listed as "pending 
implementation". As far as I can see, both have been accepted/merged 
and can be moved to "Implemented/PHP 8.3" (and updated with links to 
the implementation PRs/commits).


There may be more RFCs which may need to be moved to different 
sections on the page and/or get a status update.


May I ask the RFC authors to do so in the run up to PHP 8.3-RC ?

Smile,
Juliette

Correction: the PDO RFC has not been merged yet, so should probably be 
moved to "Pending Implementation"

Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations

[Juliette Reinders Folmer]

On 19-6-2023 23:27, Máté Kocsis wrote:

Hi Juliette,

For the mb_strimwidth() proposal an impact analysis is provided at the end
("over 100 projects were reviewed").

For the other proposals there isn't and we do not believe this to be
useful. We consider deprecations to be different from other RFCs that add
new features,
because functionality usually is deprecated because it is "harmful" in one
way or another. A large impact (i.e. broad usage) should not necessarily be
an
argument against deprecation. Please also keep in mind that a deprecation
is just that, a deprecation. It gives developers a heads up to migrate off
the
functionality at their own pace. We know that package maintainers are
bugged by users whenever a new deprecation message emerges in a new PHP
version,
but this doesn't mean maintainers must react right away.

Let us elaborate why we don't think impact analysis is needed here:

* As per the TYPE_CURRENCY constant is (a) completely non-functional and
(b) unfixable. As such any code that uses the constant is already broken and
the deprecation is just pointing this out, making the user aware.
* The CRYPT_* constants are possibly the least harmful part of the RFC, but
they still can be misleading to a new developer. They are trivially
polyfilled and
also trivially removed from existing code by replacing them with 1.
* MT_RAND_PHP is broken, because the sequences are not well-defined,
defeating any reason for seeding. More reasons are already given in the RFC.
* mt_rand() is everywhere and we don't believe anyone is denying that fact.
But this should not be a reason against deprecation. As the RFC outlines,
it is trivial to find this function misused with GitHub's search. We
believe that the depreciation benefit outweighs the costs for existing
users.
* ldap_connect() is already soft-deprecated in the documentation.

Regards,
The authors of th RFC



Hi Máté,

While I appreciate that _most_ of these will be low impact and are 
justified, I very much disagree with that for the proposed `mt_rand()` 
and friends deprecations.


There are plenty of situations where it is of absolutely no interest to 
get a crypographically secure value, like for generating some 
semi-random test data and I strongly believe the impact of these 
deprecations to be large and fixing it won't always be trivial for 
codebases which support a range of PHP versions.


As a matter of principle I believe there should be an impact analysis 
for anything being deprecated. It can inform the voters as to the 
appropriateness of the timing of the deprecation - early on in a major 
cycle vs late in a major cycle -. Others may just take it as a FYI, but 
at least they have access to the information if they wanted to assess it.


While I appreciate what you are saying about deprecations being an 
"action list to migrate at your own pace", the reality for open source 
packages is different as the sheer amount of deprecations over the past 
few years have taken huge amounts of time to address and "leaving those 
till later" is just not an option as the amount of time needed is the 
same and time can only be spend once.


To give you some idea: work related to PHP 8.0 and 8.1 has been nine 
months out of the year for each in my case for the open source projects 
I'm involved with, so no, leaving that to later is not an option.


Smile,
Juliette

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Juliette Reinders Folmer]

On 19-6-2023 23:16, Máté Kocsis wrote:

Hi,

The impact analysis on userland code seems to be missing for some of the

proposals, most notably for the proposals which I expect will have the
highest impact. I'd like to ask for an impact analysis to be added to
each of these:
* array_keys()
* ReflectionProperty::setValue()


These are intentionally left out due to different reasons:

* Even though the 1 parameter version of array_keys() is used a lot, its 2+
parameter signature is much less known.
Personally, I've never used it. Of course, this doesn't mean no one uses
it, but I don't think this deprecation will really
matter in practice, so I didn't care to write a script for this (the rest
of the deprecations were easy to analyze via regexes).

* ReflectionProperty::setValue() would be a lot of work to analyze since
it's very difficult to track whether the
setValue() method is called on a ReflectionProperty instance. Not to
mention the fact that the deprecation only affects
function invocations where either a single parameter is provided or static
properties where the first parameter is not null
or an object instance. Since the suggested alternative is basically
available since forever, I think it's OK not to do
an exhaustive analysis in this case.



For the `get*_class()` deprecation, I wonder if an additional impact
analysis is needed for packages which may not have removed usages of
`get_class( null )`, which would now be double-impacted (and not caught
by the current analysis).


I'm not sure I can follow you, but get_class(null) is a TypeError since 8.0
(and have been warning since 7.2). If a package
didn't feel the need to migrate its get_class() usages then it is likely a
dead project. And if someone tries to upgrade their
(proprietary) code from PHP 7.1 to PHP 8.3 directly then they will notice
the exception first and also - if they followed the upgrading
notes carelly - will learn the relevant suggestions regarding the
deprecation. But realistically speaking, these projects will most probably
be bound by lots of other more severe issues, so I don't think the above is
a viable upgrade path...

Regards,
Máté


Thanks for the reply Máté.

I understand what you are saying and appreciate it may be difficult to 
get an accurate impact analysis for `ReflectionProperty::setValue()`.


Respectfully though, in my opinion selectively leaving out impact 
analysis without mentioning why they are missing in the RFC, reeks of 
trying to hide information which could influence the vote.
Maybe just mentioning why the impact analysis is missing in these cases 
in the RFC could take that stench away ?


Smile,
Juliette

Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations

[Juliette Reinders Folmer]

On 15-6-2023 9:18, Máté Kocsis wrote:

Hi everyone,

As there was no discussion and complaint for a long time, we would like to
move forward with the RFC. We believe Go and Tim answered Nikita's doubts
elaborately, so we should make the question decided during the vote.

Therefore, we'll start the vote on Monday, unless new problems emerge.

Thanks,
Máté



I'm wondering why no impact analysis has been done for any of these to 
get an idea of how large the impact is on userland. Could this please be 
added to the RFC for each proposal separately ?


Smile,
Juliette

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Juliette Reinders Folmer]

On 27-4-2023 23:28, Máté Kocsis wrote:

Hi Internals,

As you have possibly already experienced, overloaded signatures cause
various smaller and bigger issues, while the concept is not natively
supported by PHP. That's why I drafted an RFC which intends to phase out
the majority of overloaded function/method signatures and also forbid
the introduction of such functions in the future:
https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures

I'm not sure at all what the best solution would be to get rid of the
overloaded FFI methods, so I hope that someone comes up with a better idea.
Currently, the RFC suggests deprecating and then removing the static
methods in question, but I hope that we can find a more elegant approach.
So this section is incomplete and it's just for starting the discussion.

Regards,
Máté



The impact analysis on userland code seems to be missing for some of the 
proposals, most notably for the proposals which I expect will have the 
highest impact. I'd like to ask for an impact analysis to be added to 
each of these:

* array_keys()
* ReflectionProperty::setValue()

For the `get*_class()` deprecation, I wonder if an additional impact 
analysis is needed for packages which may not have removed usages of 
`get_class( null )`, which would now be double-impacted (and not caught 
by the current analysis).


Smile,
Juliette

Re: [PHP-DEV] Removing support for the disable_classes INI setting

[Juliette Reinders Folmer]

On 14-8-2023 16:17, G. P. B. wrote:

Hello internals,

While working on some DNF type bugs, I discovered some major issues around
the disable_classes INI setting implementation. Such as:

- A double-free of the type of a typed property
- A use after free (which segfaults) when trying to access a property
defined on a disabled class that was extended (e.g. disabling Exception)
- A use after free when var_dumping a disabled class that has its own
handler (as it will assume properties to be allocated)
- And likely more considering the lack of tests surrounding this feature

This feature seems of dubious nature, and the only justification given when
adding support for this in the changelog of PHP 4.3.2 is:

New "disable_classes" php.ini option to allow administrators to disable
certain classes for security reasons. [1]

However, only classes defined by extensions can be disabled, and such a
class is critical for the correct operation of said extension.
As such, what one should do for security reasons is to not enable the
extension in the first place.

Moreover, compared to the behaviour of disable_functions which, as of PHP
8.0, removes the function declaration completely, disable_classes does not
remove the declaration of the class, but just "overloads" the object
creation process to not initialize the object and emit a warning.
Meaning, it is totally valid to instantiate a disabled class and pass it
around to functions for them to blow up when they try to use the object as
intended.

Considering the major flaws in the implementation of said feature, the
dubious nature of it, and the seeming lack of usage of it (considering none
of the above breaking bugs have been reported).
I would like to remove this feature in PHP 8.3, even though I know we are
past feature freeze and close to the first RC.

I have CCed the RMs for 8.3, and would like the opinion of other people on
if this removal makes sense to the majority of people

Sincerely,

George P. Banyard

[1] https://externals.io/message/2076



Hi George,

For what its worth: in my experience, the `disable_classes` and 
`disable_functions` ini directives are mostly used by hosting companies 
providing shared/virtual host environments and, most often for those 
environments, not editable by their users via a control panel or nor do 
these users have (edit) access to the php.ini file.


Declaring an ini directive in the php.ini file which has been removed 
will instantly cause a fatal error on starting PHP, so I wonder what the 
impact will be when a user switches PHP version (which they often can 
choose to do via a control panel).


Hosts should (of course) know what they are doing and this should be 
handled when the user initiates the PHP version switch, but if hosts 
knew what they were doing, they would make the extension unavailable (as 
you already suggested above), so I wonder how many shared hosting users 
will run into trouble if this is removed without deprecation period ?


Would deprecating it in PHP 8.3 and removing it in PHP 9.0 be an option ?

As for the lack of bug reports - the typical type of end users using 
those hosts will not know to report these type of issues to PHP (or even 
be able to properly identify the issue). Instead they will complain 
extensively to whatever open source project (read: WordPress) they are 
running on the shared hosting without providing enough information for 
the open source maintainers to even begin to identify the actual 
issue... ;-)


Just my two cents.

Smile,
Juliette

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

[Juliette Reinders Folmer]

On 22-1-2024 10:50, Gina P. Banyard wrote:

Hello internals,

Máté Kocsis and myself would like to propose deprecating implicitly nullable 
parameter types.

The RFC is available on the wiki at the following address:
https://wiki.php.net/rfc/deprecate-implicitly-nullable-types


Best regards,

Gina P. Banyard



For what it's worth, I support this deprecation - one less "exception to 
the rule" to have to take into account and remember.


As for the RFC:
* While I don't think the impact will be that large and the fix is 
straight-forward, I believe it would still be good to include an impact 
analysis

(top 2000 Packagist packages check) in the RFC to confirm this.
* The RFC currently only talks about deprecating the syntax in PHP 8.4 
and makes no mention of removing support for the syntax altogether
in the future. Would it be an idea to include a proposal for 
removal of the syntax in the RFC ?
* The RFC does not mention the impact of the function signature change 
on inheritance. I think it would be good to clarify that there is none.
The changes will not cause an LSP violation in case of inheritance 
and can be made for parent/child classes independently of each other.

Also see: https://3v4l.org/0qM7W
* While the majority of projects will (hopefully) be able to use 
nullable types/union types with null to mitigate the deprecation,
there are still projects which have a wide range of supported PHP 
versions with the minimum being below PHP 7.1 (yes, WordPress I'm 
looking at you).


It might be worth mentioning in the "Backward incompatible changes" 
section what the options are for those projects to mitigate the deprecation.

As far as I can see, that would come down to the following options:
1. [Best option] Raise the minimum supported PHP version to 7.1, 
use nullable types and remove the `null` default value.
Including a code sample like the 3v4l I posted above should 
probably also help clarify the expected change to the code.
2. Removing the default value without making the type nullable. 
This would be a signature change and could cause problems
if the parameter was previously optional, but that's for the 
project itself to make a judgment call on.
3. For scalar and array typed parameters, changing the default 
value to one which complies with the type. Again, this would
 be a signature change and in this case, it could cause 
problems if the parameter was previously required and not
 the last parameter before optional ones, but again, that's for 
the project itself to make a judgment call on.
4. Remove the type declaration + if the parameter is/was required, 
remove the default value. This would be a huge step backwards,
 but would still allow for making those signatures 
cross-version compatible. This again, would be a signature change and this
 would be one which would violate LSP in case of inheritance, 
but again, that's for the project itself to make a judgment call on.


Hope I've captured all options, though not claiming completeness.

Hope this helps.

Smile,
Juliette

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

[Juliette Reinders Folmer]

On 23-1-2024 3:18, Gina P. Banyard wrote:

The RFC notes that PHPStan and friends have an easy flag to make the change, 
which is great, but still that's a minority of PHP devs that even know to use 
static analysis.

One does not need to use a static analyser to determine or fix this issue, 
indeed, I didn't even mention static analysers in the RFC as PHP_CS_FIXER is a 
tool for enforcing coding styles and is capable of fixing this issue.
This tool and other code formatting tools are used more widely and for longer 
than static analysers.
While I concur that too few devs use the helpful tooling available to 
them, I can already tell you that PHPCompatibility for PHP_CodeSniffer 
will be able to detect and flag code subject to this deprecation without 
problems and I will make sure the sniff is available ahead of the PHP 
8.4 release (providing the RFC passes).


And the Slevomat Coding Standard for PHP_CodeSniffer already contains 
the `SlevomatCodingStandard.TypeHints.NullableTypeForNullDefaultValue` 
sniff to auto-fix non-nullable typed parameters with a `null` default 
value to be nullable typed as well, so it's not just CS-Fixer which can 
help with this.


Smile,
Juliette

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

[Juliette Reinders Folmer]

On 6-2-2024 3:40, youkidearitai wrote:

2024年2月6日(火) 8:33 Tim Starling :

On 2/2/24 20:27, youkidearitai wrote:

I see. I'll change mb_ucfirst using titlecase.

Per my comments a month ago on the GitHub issue , I think it is much better to 
use title case for mb_ucfirst() than to use upper case, since conversion of the 
first character to upper case has the effect of corrupting text in the Georgian 
script, and initial lower-case ligatures are converted to a form which appears 
like two upper case letters. So I'm pleased to see this change to the PR.

I would appreciate it if the RFC could also be updated to include this detail, 
since my vote depends on whether title case or upper case will be used.

-- Tim Starling

Hi, Tim

Thank you for your comment.
I modified to "uses unicode case title" in an RFC.

Regards
Yuya



Help me out here, but doesn't changing what is actually proposed in an 
RFC **after** the vote has started invalidate the vote ?


Shouldn't the vote be closed/withdrawn and restarted in that case ?

[PHP-DEV] What is the prevailing sentiment about extract() and compact() ?

[Juliette Reinders Folmer]

L.S.,

What with all the drives towards cleaner code, how do people feel 
nowadays about `extract()` and `compact()` still being supported ?


Both have alternatives. The alternatives may be a little more cumbersome 
to type, but also make the code more descriptive, lessens the risk of 
variable name collisions (though this can be handled via the $flags in 
extract), prevents surprises when a non-associative key would be 
included in an array and lessens security risks when used on untrusted data


function foo() {
$array = [
'color' => 'blue',
'size'  => 'medium',
];

// Using extract.
extract($array);
var_dump($color);

// Not using extract.
var_dump($array['color']);

$color = $array['color'];
var_dump($color);
}

function bar( $color, $size ) {
// Using compact.
$array = compact('color', 'size');
var_dump($array);

// Not using compact.
$array = [
'color' => $color,
'size'  => $size,
];
var_dump($array);

$array = [];
foreach (['color', 'size'] as $name) {
if (isset($$name)) {
$array[$name] =  $$name;
}
}
var_dump($array);
}

https://3v4l.org/JeHnY


I can imagine these could be candidates for deprecation ? Or limited 
deprecation - only when used in the global namespace ?


For now, I'm just wondering how people feel about these functions.

Smile,
Juliette

Re: [PHP-DEV] [RFC] [Discussion] Release cycle update

[Juliette Reinders Folmer]

On 10-11-2023 17:51, Jakub Zelenka wrote:

Hello,

I would like to propose a new process RFC for updates to PHP release cycle:

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

This has been discussed between release managers to make sure that all are
happy as some of the points impact release managers (e.g. longer security
support).

I also opened a PR to my new personal repo for RFC's if anyone has got any
suggestion for better wording or notices any typo:

https://github.com/bukka/php-rfc/pull/1



Thank you Jakub for putting this together. A lot of this makes sense to 
me, but the shortening of the feature freeze period from effectively 18 
weeks (with some exceptions) to 8 weeks concerns me.


While this is not a concern for applications in a controlled 
environment, this is a concern for open source projects which don't have 
control over the environment the software is being run on and therefore 
generally "have to be" (try to be) deprecation-free "early", especially 
packages which are used in the CI/QA chain of open source applications 
(think: Composer, PHPUnit, Mockery, Pest etc) and frameworks which are 
widely extended, where the extensions can't really verify their own 
readiness until the framework is deprecation-free (think: WordPress and 
its plugin system).


Taking that into account, I would like suggest the following:
* Yes, 4 RCs, but instead of 2 weeks between each, have 3 weeks between 
each. That way the RC period remains the same, allowing the open source 
world to get ready in time, while still lessening the workload.
* Regarding moving the feature freeze to the first RC: I can see the 
benefits of small features still being allowed in, but deprecations 
going in late is a different matter. While PHP 8.3 was "light" in 
regards to the impact of deprecations, PHP 8.1 and 8.2 were a whole 
different kettle of fish. With that in mind, I'd like to suggest 
deprecations/removals to only be allowed in up to beta 1, with new RFC 
features and other small changes being allowed in until RC1.


I hope you'll consider these suggestions.

Smile,
Juliette

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Juliette Reinders Folmer]

On 9-4-2024 16:03, Juliette Reinders Folmer wrote:

On 8-4-2024 23:39, Ilija Tovilo wrote:

Hi everyone

Heads-up: Larry and I would like to start the vote of the property
hooks RFC tomorrow:
https://wiki.php.net/rfc/property-hooks

We have worked long and hard on this RFC, and hope that we have found
some middle-ground that works for the majority. One last concern we
have not officially clarified on the list:

https://externals.io/message/122445#122667


I personally do not feel strongly about whether asymmetric types make it into 
the initial implementation. Larry does, however, and I think it is not fair to 
exclude them without providing any concrete reasons not to. [snip]

My concern is more about the external impact of what is effectively a change to 
the type system of the language: [snip] will tools like PhpStan and Psalm 
require complex changes to analyse code using such properties?

In particular, this paragraph is referencing the ability to widen the
accepted $value parameter type of the set hook, described at the
bottom ofhttps://wiki.php.net/rfc/property-hooks#set. I have talked
to Ondřej Mirtes, the maintainer of PHPStan, and he confirmed that
this should not be complex to implement in PHPStan. In fact, PHPStan
already offers the @property-read and @property-write class
annotations, which can be used to describe "virtual" properties
handled within __get/__set, already providing asymmetric types of
sorts. Hence, this concern should be a non-issue.

Thank you to everybody who has contributed to the discussion!

Ilija



Ilija,

Heads-up: I'm still writing up an opinion and intend to send it to the 
list before end of day (CET). I know I'm late to the party, but I've 
been having trouble finding the words to express myself properly 
regarding this RFC (and have been struggling to find the right words 
for months).


Smile,
Juliette


Later than intended, but here goes

If there is one RFC which has been giving me nightmares since I first 
heard of it, it's this one.


I realize it is late in the discussion period to speak up, but for 
months I've been trying to find the words to express my concerns in a 
polite and constructive way and have failed.


I am going to try now anyway (before it is too late), so please bear 
with me. Also, as I'm not a C-developer, please forgive me if I get the 
internals wrong. I'm writing this from a PHP-dev/user perspective, with 
my perspective being heavily influenced by my role as maintainer of 
PHP_CodeSniffer.


---
TL;DR: this RFC tries to do too much in one go and introduces a huge 
amount of cognitive complexity with all the exceptions and the 
differences in behaviour between virtual and backed properties. This 
cognitive complexity is so high that I expect that the feature will 
catch most developers out a lot of the time.

---

I can definitely see the use case and desirability of the property hooks 
functionality proposed in the RFC and compared to the initial RFC I read 
last year, the current RFC is, IMO, much improved.

Huge kudos to Ilija and Larry for all the work they have put in to this!

I applaud the intention of this RFC to make it easier to avoid the magic 
__get()/__set() et al methods. What I have a problem with is the 
implementation details.


Over the last few years, we've seen a movement to get rid of more and 
more of the _surprising_ behaviour of PHP, with subtle exceptions being 
deprecated and slated for removal and (most) new syntaxes trying to use 
the principle of least surprise by design.


This RFC, in my view, is in stark contrast to this as it introduces a 
plethora of exceptions and subtle different behaviour in a way that will 
catch developers out for years to come.


At this moment (excluding property hooks), from a user perspective, 
there are three different function syntaxes in PHP: named functions (and 
methods), anonymous functions and arrow functions.


The semantics of these are very similar with subtle differences:
* Can be static or non-static.
* Take parameters, which can be typed, references, variadic, optional etc.
* Can have a return type.
* Can return by reference.
* Have a function "body".

The differences between the current syntaxes - from a user perspective - 
are as follows:

= Named functions:
* When declared in a class, can have visibility attached, can be 
abstract, can be final.
* When declared in an interface or declared as abstract, will not have a 
function "body".


= Anonymous functions:
* Can import plain variables from outside its scope with a `use()` clause.
* Are declared as an expression (can be assigned to a variable etc).

= Arrow functions:
* Have access to variables in the same scope.
* Are declared as an expression.
* Body of the function starts with a => instead of being enclosed in 
curlies and can end on a range of characters.

* Can only take one statement in the body.
* Automagically returns.

The property hooks RFC introduces a 

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Juliette Reinders Folmer]

Hi Ilija,

On 12-4-2024 1:00, Ilija Tovilo wrote:

On 9-4-2024 16:03, Juliette Reinders Folmer wrote:

I realize it is late in the discussion period to speak up, but for months I've 
been trying to find the words to express my concerns in a polite and 
constructive way and have failed.

First of all, thank you for taking the time to analyze the RFC and
form your thoughts. I know how much time and effort it takes.
Nonetheless, I hope you understand that receiving feedback of this
sort literally minutes before a vote is planned is close to the worst
way to go about it, both from a practical standpoint, but also RFC
author and reviewer morale.
Many of the points you raise have been there for many months to a
year, and many have been raised and discussed many times over.


Thank you for your extensive response.

No matter how much time I spend trying to voice my concerns properly, I 
clearly still failed.


My email was not a criticism of the work on property hooks as such. It 
was, more than anything, an opinion piece.


The first part of my email (up to the "Furthermore") was mostly me 
trying to summarize the complexity of the proposal and to compare it to 
existing syntaxes and list those things which - to me - appeared 
inconsistent with other PHP features. It was not intended as criticism 
on individual choices made and I'm not sure whether, if I were designing 
this feature, I would have made different choices, other than to have 
just one syntax - the "full" syntax (with a `get();`/`set();` variant - 
yes, always with parentheses - for abstract/interface properties).


This first part was meant as a summation to highlight how incredibly 
complex this new feature is and how many opportunities it offers 
developers to shoot themselves in the foot.
Let alone, how many problems this can cause when developers use classes 
in dependencies which use this new feature and they have limited to no 
awareness of whether they are using virtual or backed properties on the 
dependency.


As the proposal purports to be a better alternative to the magic 
`_get()`/`__set()` methods, I would expect it to prevent a lot of the 
problems associated with those methods. However, what I found - and what 
you seemingly confirmed in your reply - is that this new feature does 
*not* in actual fact solve the problems magic methods have. It has the 
same problems + more problems associated with the new feature itself.


Part of my concern is therefore that this feature adds significant extra 
complexity to the engine, for little to no real benefit, other than to 
have a nicer syntax for creating the same problems we already had before.


In that sense, my email was not to ask you to make changes to the 
proposal [*], but far more to try and make sure that those people with 
the power to vote and without the time to fully read and really grep the 
(really really long) proposal, are put in a position to make an informed 
choice.


[*] The part after the "Furthermore" did contain some criticism, where 
my points marked with [2] and [3] are AFAICS just a matter of clarifying 
things in the RFC, while [1] and [4] would possibly warrant changes, 
though I would expect (hope) the impact of those in dev time to be small.
Oh and yes, my remark about `var` would also warrant a change in the RFC 
text.


I can see that those textual changes in the RFC have been made in the 
mean time, so thank you for adding the additional clarifications for 
those points to the RFC.


As for [1] and [4], let me respond to your answers to those points:


[1] Additionally, it proposes for isset() to throw an Error for virtual 
properties without a get hook. This is surprising behaviour as isset() by its 
nature is expected to *not* throw errors, but return false for whatever is not 
set or inaccessible from the current context: https://3v4l.org/3OlgM

Personally, I would rather know when checking `isset` on something
that can never return `true`. But I admit that this case is not
clear-cut. The throwing approach can be relaxed to return false
without a BC break though, but not the opposite.


In my opinion, a plain call to `isset()` should never have to be put in 
a try-catch, but I understand your point about being conservative now 
and being able to relax the approach later without BC-break.


I would definitely be in favour of relaxing the approach to make 
`isset()` return false, but let's see what other have to say about it.



[4] Why should ReflectionProperty::getRawValue() throw an error for static 
properties ? Instead of returning the value, identically to 
ReflectionProperty::getValue() ? This is surprising to me and I see no reason 
for it.

Because it's equivalent to `getValue`, and indicates the user is doing
something they don't fully understand.


Except that it isn't equivalent behaviour, as `getValue()` will return 
the value for both static and non-static properties without any problems.
See: https:/

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

[Juliette Reinders Folmer]

On 8-5-2024 15:40, Gina P. Banyard wrote:

I would like to formally propose my idea for exit() as a function brought up to 
the list on 2024-02-24 [1] with the following RFC:
https://wiki.php.net/rfc/exit-as-function

There have been some slight tweaks to the implementation, namely that the transformation 
from a "constant" to a function is done at compile time and we do not hook into 
the behaviour of constants any longer.


No objections from my side, though, yes, PHPCS will need to be 
updated/adjusted to work around this, but that's no biggie.


When reading the RFC, there are two things about which I still have 
questions.


1. As things are, `exit` and `die` cannot be used as a label for a goto 
statement.


```php
goto exit;

exit:
  echo 'exited';
```
https://3v4l.org/fluuk and https://3v4l.org/cNMEW

Will that change now `exit` would no longer be a reserved keyword ?

2. The RFC mentions the "old" semantics regarding type juggling for 
exit/die - always cast to string - and it mentions that passing 
resources or arrays in the new situation will become a TypeError, but 
that still leaves some room for interpretation for the other types, in 
particular the handling of booleans.


How I read the RFC, the type juggling would change as follows (but I may 
well be wrong!):


| Param passed  | Old | New   | Consequences |
|---|-|---|---|
| integer   | integer | integer   | No change, interpreted 
as exit code |
| string| string  | string| No change, interpreted 
as status message |
| bool  | string  | integer   | Was status message, now 
exit code |
| float | string  | integer   | Was status message, now 
exit code, "Implicit conversion from float to int loses precision" 
deprecation notice |
| null  | string  | integer   | Was status message, now 
exit code, "Passing null to parameter #1 ($status) of type string\|int 
is deprecated" |
| stringable object | string  | string| No change, interpreted 
as status message |

| non-stringable object | string  | TypeError | |
| array | string  | TypeError | |
| resource  | string  | TypeError | |

Might it be an idea to make all the type juggling changes explicit in 
the RFC ? (and correct whatever I interpreted incorrectly)


Smile,
Juliette

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

[Juliette Reinders Folmer]

On 11-5-2024 16:43, Gina P. Banyard wrote:


On Thursday, 9 May 2024 at 15:17, Jorg Sowa  wrote:

> I don't think there are any other "functions" like this.

What about list(), isset(), print(), echo(), require(), include(), 
unset(), empty()? We use them the same way as functions, but those 
are not real functions.




list() (and array()) may look like functions but do not behave like 
one as they affect the current scope by setting various variables.


isset()/empty()/unset() require to work with undefined variables and 
have deeply ingrained behaviour within the engine, so making them 
simple functions is not as much of a "trivial" change.


print, echo, include(_once) and require(_once) do not mandate their 
"argument" to be passed within parenthethis, so making them functions 
does not simplify the lexer/parser nor removes them as keywords.
Also I don't know the last time I've used those language constructs 
"like a function".




Seeing this list, makes me wonder: what about eval() ?

Re: [PHP-DEV] Re: [PHP-CVS] [php-src] master: Deprecate implicit nullable parameter types (#12959)

[Juliette Reinders Folmer]

On 14-3-2024 15:55, Matteo Beccati wrote:

Hi Sebastian,

Il 14/03/2024 14:15, Sebastian Bergmann ha scritto:

Am 14.03.2024 um 14:07 schrieb Matteo Beccati:

In my daily CI I have several builds failing today, eg.

* PHPUnit 9.6


See https://github.com/sebastianbergmann/phpunit/issues/5719.


thanks, I had a quick look in the open issues and didn't find anything.

Kudos for looking into it way ahead of the actual merge of the PR to 
master.



Cheers



For whomever is interested:

I've already worked up sniffs for PHPCompatibility [1] to flag the 
deprecation. The sniffs should be able to help find any issues with high 
precision.


I'm waiting on an update of `git.master` on 3v4l.org [2] to validate the 
sniffs are matching the PHP native behaviour exactly.
Once I have been able to validate, the sniffs will be made publicly 
available. (hopefully in a day or two)


Smile,
Juliette

1: https://github.com/PHPCompatibility/PHPCompatibility
2: https://phpc.social/@jrf_nl/112091061544484825

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

[Juliette Reinders Folmer]

On 6-4-2024 14:55, Tim Düsterhus wrote:

Hi

On 4/5/24 23:32, Juliette Reinders Folmer wrote:

I also took the liberty to ask accessibility expert Nicolas Steenhout
[1] for his opinion on this topic and he has given me permission to
quote his reply:

  > From a human readability and an accessibility perspective, Camel 
Case

are best when words are concatenated like that.
  > The rule I’d use here is uppercase the first letter of a word. Then
lowercase the others. Unless you are writing an acronym.
  > So in your example, it should be `PerformHTTPRequest()`
  > The underscore becomes a problem because if for some reason we’re
writing code as an example and it gets underline for any reason, the
underline gets lost



Thank you. I must admit I find it a little hard to interpret the 
answer without also seeing the corresponding question, because the way 
the question was phrased might've influenced the answer.


While I personally disagree with the acronym casing, it is not too bad 
in the example identifier used ("Perform HTTP Request"). However the 
naming policy will not just need to make the average case look great, 
but also make the worst case look acceptable. If it cannot do so and 
needs exceptions, then it failed to be a useful policy.


Hoping it isn't too much of a request, would you mind asking Nicolas 
whether the answer changes, when facing the following extreme examples 
consisting of consecutive acronyms.


I'm intentionally writing them in their natural casing with spaces to 
hopefully not influence the response:


1.

PCG Oneseq 128 XSL RR 64

which for reference is "Permuted Congruential Generator One Sequence 
128-Bit state XorShift Low Bits Random Rotation with 64-Bit Output", 
with the abbreviations / acronyms matching the naming in the reference 
implementation / corresponding paper.


2.

PDO ODBC

which is "PHP Data Object Open Database Connectivity", but no one 
writes those acronyms out in full.


3.

XML HTTP Request

which is "eXtensible Markup Language HyperText Transfer Protocol 
Request". I'd argue that the name is not really descriptive in the 
first place, but it's another existing real-world example.


4.

UUID v4

Taken from Ben Ramsey’s UUID library: 
https://github.com/ramsey/uuid/tree/4.x/src/Rfc4122


5.

S3 Client

as in "Amazon Simple Storage Service Client". Taken from Flysystem: 
https://github.com/thephpleague/flysystem/blob/3.x/src/AwsS3V3/S3ClientStub.php


Best regards
Tim Düsterhus



Hi Tim,

I forwarded your questions from above verbatim to Nicolas and this was 
his response (also quoted verbatim):


> So, this one is interesting.
> Sure, if you look at these extremes, stringing them back to back all 
in a uppercase, they are not particularly user-friendly to read.
> Then again, none of these solutions are super user-friendly. We are 
dealing with making the best of things.
> I have to say, it always gets my goat a little bit when people raise 
“the extremes” in the context of accessibility. Somehow it always ends 
up feeling like, to me at least, like a copout.
> Like, sure if you have someone who is blind, deaf, and paralyzed from 
a stroke, making something accessible to them is going to be extremely 
difficult. It doesn’t mean you shouldn’t make things accessible to 
people who are blind, to people who are deaf, and to people who are 
paralyzed from a stroke.
> This is a little bit like that. The solution I proposed earlier may 
not work for everybody. But it will work for a majority.


Smile,
Juliette

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Juliette Reinders Folmer]

On 8-4-2024 23:39, Ilija Tovilo wrote:

Hi everyone

Heads-up: Larry and I would like to start the vote of the property
hooks RFC tomorrow:
https://wiki.php.net/rfc/property-hooks

We have worked long and hard on this RFC, and hope that we have found
some middle-ground that works for the majority. One last concern we
have not officially clarified on the list:

https://externals.io/message/122445#122667


I personally do not feel strongly about whether asymmetric types make it into 
the initial implementation. Larry does, however, and I think it is not fair to 
exclude them without providing any concrete reasons not to. [snip]

My concern is more about the external impact of what is effectively a change to 
the type system of the language: [snip] will tools like PhpStan and Psalm 
require complex changes to analyse code using such properties?

In particular, this paragraph is referencing the ability to widen the
accepted $value parameter type of the set hook, described at the
bottom of https://wiki.php.net/rfc/property-hooks#set. I have talked
to Ondřej Mirtes, the maintainer of PHPStan, and he confirmed that
this should not be complex to implement in PHPStan. In fact, PHPStan
already offers the @property-read and @property-write class
annotations, which can be used to describe "virtual" properties
handled within __get/__set, already providing asymmetric types of
sorts. Hence, this concern should be a non-issue.

Thank you to everybody who has contributed to the discussion!

Ilija



Ilija,

Heads-up: I'm still writing up an opinion and intend to send it to the 
list before end of day (CET). I know I'm late to the party, but I've 
been having trouble finding the words to express myself properly 
regarding this RFC (and have been struggling to find the right words for 
months).


Smile,
Juliette

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

[Juliette Reinders Folmer]

On 5-4-2024 19:48, Niels Dossche wrote:

On 05/04/2024 19:00, Tim Düsterhus wrote:

I've just written up the follow-up RFC to my previous “Casing of acronyms in 
class and method names” thread and I'm officially opening up the discussion 
period for it.

Please find the following links for your convenience:

RFC: https://wiki.php.net/rfc/class-naming-acronyms
Previous ML discussion: https://externals.io/message/120959#120959
Related discussion in PHP-FIG: 
https://github.com/php-fig/per-coding-style/issues/83


Tim,

In the "It decreases readability" section you make a sweeping statement 
about accessibility, but don't back that up with research. Please back 
your statement up as based on my understanding, the opposite is true.


Case in point: if written in all caps, screenreaders will spell the 
characters out - think HTML -. If written in Mixed case, screenreaders 
will try to pronounce the word, making acronyms and other abbreviations 
very hard to understand for anyone using a screenreader.


This is something which has repeatedly been pointed out, for instance at 
conferences regarding conference acronym hashtags, like #DPC.


So, I'd be very interested to see your statement backed up by actual 
research and invite you to look into this a little deeper.




I support this proposal.
If accepted, I'll make the necessary changes to ext-dom and ext-xsl to comply 
with the new policy.
Niels: just wondering what changes you are referring to ? The RFC 
explicitly states "Existing class and method names in released versions 
are not affected"... ?



Smile,
Juliette

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

[Juliette Reinders Folmer]

On 5-4-2024 22:55, Larry Garfield wrote:

On Fri, Apr 5, 2024, at 7:15 PM, Tim Düsterhus wrote:

Hi

On 4/5/24 20:01, Juliette Reinders Folmer wrote:

In the "It decreases readability" section you make a sweeping statement
about accessibility, but don't back that up with research. Please back
your statement up as based on my understanding, the opposite is true.

For context: This paragraph was added by Larry. It's my name on the RFC
of course and I approved of the addition he made. Nevertheless Larry
might've additional resources to add here.


Case in point: if written in all caps, screenreaders will spell the
characters out - think HTML -. If written in Mixed case, screenreaders
will try to pronounce the word, making acronyms and other abbreviations
very hard to understand for anyone using a screenreader.

This is something which has repeatedly been pointed out, for instance at
conferences regarding conference acronym hashtags, like #DPC.

So, I'd be very interested to see your statement backed up by actual
research and invite you to look into this a little deeper.

Your remark looks at the accessibility from the PoV of a developer with
impaired eyesight that is dependent on assistive technology. However
accessibility also affects developers with regular vision. The concerns
of these two groups might conflict.

W3C's accessibility guidelines point out that:

  > Text in all capital letters is more difficult to read for most
people, with and without disabilities.

(https://w3c.github.io/low-vision-a11y-tf/requirements.html#capitalization)

Harvards's Accessibility Guidelines agree:

  > Avoid using all caps. Readability is reduced with all caps because
all words have a uniform rectangular shape, meaning readers can't
identify words by their shape.

(https://accessibility.huit.harvard.edu/design-readability)

Of course program identifiers are not regular text and indeed more
similar to hashtags, in that they do not permit the inclusion of
whitespace to separate words. Underscores would work, but that would
just add to the inconsistency.

For Hashtags I found several resources pointing out to capitalize each
word separately. For acronyms most resources pointed out that they
should be avoided entirely (e.g.
https://studentlife.mit.edu/das/accessibility/digital-accessibility/socialmedia,
https://www.nyu.edu/life/information-technology/web-and-digital-publishing/digital-publishing/accessibility/how-to-guides/social-media.html#acronyms)
and that recommendation is already part of the existing guidelines.

I've tested with my Android phone with the 'performHttpRequest' example
and both variants where read out equally terrible as 'per-form age tee
tee pre-quest' (i.e. merging the p with the request). And your example
of HTML was read out as 'age tee em el' (or rather the German
pronounciation of the letters) for both HTML and Html. The lack of
vowels might've helped with the result, though.

The case of the boundary between two consecutive acronyms being unclear
should affect developers with regular vision and impaired vision alike
(i.e. PDOODBC and XSLRR).

  From my personal experience as a human with regular vision (not even
glasses), the variant of treating acronyms as regular words is much
easier to parse.

Best regards
Tim Düsterhus

Thanks Tim.  Those are the same resources I was going to cite. :-)  I'll also 
add

>From the APA: 
https://apastyle.apa.org/style-grammar-guidelines/paper-format/accessibility/typography

"It is true that presenting text in all caps will slow down all readers, especially 
those with certain types of visual and/or cognitive impairments."

(They then go on to recommend using proper casing in the source and CSS styles 
to capitalize things, so that screen readers ignore it, which seems dumb to me 
given the other resources cited above.)

And from the a11y Project: 
https://www.a11yproject.com/posts/how-to-accessible-heading-structure/#all-caps

"Text in all capitals is harder to read. The shape of a word disappears, every word 
becomes a rectangle. Research shows that all caps text is especially difficult for 
readers with dyslexia. Make life easy for your readers, don't capitalize all the 
words."

So the professional consensus among accessibility and publishing organizations 
is absolutely that ALLCAPS is bad for readability and accessibility.

I've added some of the links above to the RFC for citation.

--Larry Garfield



Larry, Tim,

Thank you both for your responses. I think it would be a good idea to 
include these sources in the RFC.


I also took the liberty to ask accessibility expert Nicolas Steenhout 
[1] for his opinion on this topic and he has given me permission to 
quote his reply:


> From a human readability and an accessibility perspective, Camel Case 
are best when words are concatenated like that.
> The rule I’d use here is uppercase the first letter of a word. Then 
lowercase the others. Unless you are writing

Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions

[Juliette Reinders Folmer]

On 24-2-2024 2:37, Gina P. Banyard wrote:

Hello internals,

I've been having this mild annoyance with exit()/die() since I wrote a CLI
script using a boolean $hasErrors variable to know if the script failed or not
and to indicate if the script failed via a non-zero status code by doing:
exit($hasErrors);

However, it turns this doesn't work, because exit() will cast everything
that is not an integer to a string, something that I find surprising but
also weird as it will not type error on resources or array but rather print
the warning to the CLI.

Anyway, yesterday I decided to put on my mad scientist lab coat and make this
a reality, I have a W.I.P. PR here:
https://github.com/php/php-src/pull/13483

I hear you, but what about exit; ?!
Do not worry exit; is still supported!
It only requires a _tiny_ bit of dark magic to achieve this!
exit; would just be interpreted as a fetch to a constant,
so when attempting to access the undefined exit/die case-insensitive constant
we just need to exit as if we were calling the function!

Having exit and die be functions gives us access to some interesting
functionality, such as defining exit() in a namespace, or removing it via the
disable_functions INI setting (the latter allowing us to define a custom global
exit() which could be useful for testing that a function actually calls exit).

We can also pass it like any other callable and reflect on it with reflection.

Finally, this removes the T_EXIT token and ZEND_EXIT opcode freeing one slot.

The W.I.P. PR implement every possible restriction:
  - not being able to declare an exit()/die() function
  - not being able to disable them
  - not being able to define a constant named exit/die

Maybe it would be wise to deprecate using exit as a statement to be able to get
rid of the undefined constant magic handling.

Anyhoot, before I spend more time on this and write a proper RFC, do people
think this is a good idea or not?


Best regards,

Gina P. Banyard



Hi Gina,

I'm not sure a pet-peeve is a good motivation for creating an (I expect 
large) breaking change.


The upgrade path, I suppose, would be updating calls to `die`/`exit` to 
always have parentheses ? Or alternatively changing those calls to new 
throw expressions ?


While that shouldn't be that huge a problem for real codebases (and 
would be auto-fixable for adding the parentheses), the bigger problem I 
see is the huge amount of teaching materials, tutorials and blog posts 
using the versions without parentheses which will now all be 
invalidated. I think the pain and confusion that will cause for a change 
like this, will linger for years and years.


Smile,
Juliette

Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions

[Juliette Reinders Folmer]

On 24-2-2024 3:47, Gina P. Banyard wrote:



On Saturday, 24 February 2024 at 01:57, Juliette Reinders Folmer 
 wrote:



Hi Gina,

I'm not sure a pet-peeve is a good motivation for creating an (I 
expect large) breaking change.


The upgrade path, I suppose, would be updating calls to `die`/`exit` 
to always have parentheses ? Or alternatively changing those calls to 
new throw expressions ?


While that shouldn't be that huge a problem for real codebases (and 
would be auto-fixable for adding the parentheses), the bigger problem 
I see is the huge amount of teaching materials, tutorials and blog 
posts using the versions without parentheses which will now all be 
invalidated. I think the pain and confusion that will cause for a 
change like this, will linger for years and years.


Smile,
Juliette



I didn't actually know one could do exit;
But like I said, it is extremely easy to support, and the current PR 
does support it by hooking into the undefined constant code in the engine.

I don't have strong opinions about removing support for this.
However, I do have strong opinions about changing the type juggling 
semantics of exit() to be the usual ones, because the current one is 
just confusing.
I am also not sure what would make this a large breaking change, as 
changing this from a language construct to a function provides us with 
more capabilities.




Ah, I think I missed the part about the syntax both with and without 
parentheses still being supported, with the "with parentheses" mapping 
to a function call and the "without parentheses" mapping to a 
case-insensitive constant.


In that case, I don't see a BC-break and I would regard this as an 
"under the hood" change with only a very subtle, minimal impact (the 
type checking part if a param is passed).


I do wonder what the documentation would look like as it would leave it 
as a function, but one with a special status, in that there is a native 
constant of the same name which will enforce the same behaviour.


Smile,
Juliette

Re: [PHP-DEV] [DISCUSSION] Checking uninitialized class properties

[Juliette Reinders Folmer]

On 20-5-2024 19:41, Erick de Azevedo Lima wrote:
> All of which is to say that, yes, there are use cases for an "is 
this property initialized" check that is less fugly than the 
get_object_vars() hack I have to rely on now.


I'd like to see this:

if ($objectVar->property is uninitialized) {
...
}

or/and:

if ($objectVar->property is initialized) {
...
}

--
Erick de Azevedo Lima

Em seg., 20 de mai. de 2024 às 14:28, Larry Garfield 
mailto:la...@garfieldtech.com>> escreveu:


On Sat, May 18, 2024, at 5:41 PM, Rowan Tommins [IMSoP] wrote:
> On 18 May 2024 17:13:49 BST, Larry Garfield
mailto:la...@garfieldtech.com>> wrote:
>>However, that breaks down with readonly properties, which are
not allowed to have a sentinel.  Uninitialized is their sentinel,
for better or worse.
>
> Sorry, I don't understand this statement at all. A readonly
property
> can be set to PatchState::KeepCurrentValue just like any other.
If the
> intention is that that state will be overwritten with an actual
value
> later, then it's not a readonly property.
>
> I guess you have some different scenario in mind?
>
>
>> And as I noted earlier in the thread, when writing a serializer
or other dynamic systems (an ORM probably would have the same
issue), you really need to be able to differentiate between null
and uninitialized.  Even if you think the uninitialized value is a
sign of an error, it's coming from code you don't control so you
have to be able to handle it somehow.
>
> If a property is uninitialized, the object is in an invalid
state, and
> attempting to read that property gives an error. That's by
design, and
> as it should be.
>
> Are you saying that you want to be able to detect the error
before it
> happens? Why?

For context, remember I maintain a serializer library, so I have
to support objects that may indeed be in an invalid state, and
depending on the incoming data may not be able to guarantee an
object is in a valid state.  I have to do everything via
reflection and/or visibility-busting closures. I also maintain an
attributes library that, necessarily, has multiple methods that
get called post-constructor before the object is "ready." 
Admittedly neither of these are common cases, but neither are they

invalid cases.

Readonly's current design, and the (IMO, very bad) support from SA
tools, works on the assumption that your readonly properties are
1. Based on constructor params; 2. are always guaranteed set after
the constructor.  While those are true in the majority case,
they're not true in the universal case.

IOW, "this readonly property is not set by the time the
constructor is done, so your object is invalid, so your argument
is invalid" is not a fair or accurate statement.  And even then,
lots of code needs to be able to inspect an object to determine if
it is valid or not, even if just to give the user a better error
message than "Oops, you tried to read an uninitialized property,
we gonna crash now."  (As noted, I maintain multiple such
libraries.  ORMs would be the other big use case, I think.)

All of which is to say that, yes, there are use cases for an "is
this property initialized" check that is less fugly than the
get_object_vars() hack I have to rely on now.

--Larry Garfield




If we're talking syntax and introducing new keywords anyway, why not go 
with a new language construct like `is_initialized($obj->property)` ?