[PHP-DEV] Add another php syntax for simplify code

[chopins xiao]

0. when dot object opeator is enable, use small sign and add sign [<+]  be 
equivalent to [.] for string concat mark.
 compatibility is achieved through configuration switches.
 syntax ：
  >>> $a = 'str0';
  >>> $a .= 'str1' <+ 'str2' <+ 'str3' <+ $str_var <+ strcall();
  the concat equal sign[.=] not change

1. use dot mark[.] same with [->]
 syntax:
  >>> $a = new stdClass;
  >>> $a.b  =1;   same with $a->b = 1  when dot object opeator is 
enable in php.ini
  >>> $a.get();same with $a->get()  when dot object opeator is 
enable in php.ini

2. colon [:] same with [=>] in array declaration statement
 syntax:
  >>> $a = [ 'b' : 1, 'c' : 3 ]; same with $a = ['b'=>1,  'c' => 3]

3. another class declaration statement,  cant not use [extends] and [implement] 
keyword
 syntax:
  >>> class Objects(ParentClass): Interface1,Interface2 {} 
  same with
  >>> class Objects extends ParentClass implement Interface1,Interface2 
{} 

 anonymous class
 >>> $obj = new($arg1,$arg2) class(ParentClass) : implement 
Interface1,Interface2 {} 
 same with
 >>> $obj = new class($arg1,$arg2) extends ParentClass implement 
Interface1,Interface2{}

5. another class method declaration statement,  omit [function] keyword is 
allowable
 syntax:   
  >>> public method_name($args) {}
  same with
  >>> public function method_name($args) {}

6. restriction public magic method synax sugar, omit [public][function] 
keywords and duoble underline[__] is allowable, only __get()  __set() __call() 
__callStatic() __toString()  __sleep()  __wakeup()  __serialize()  
__unserialize() is availabled
  syntax:
  >>>  class A {
  >>>   get() {
  >>>}
  >>>call() {
  >>>}
  >>>  }
  same with:
  >>>  class A {
  >>>   public function __get() {
  >>>   }
  >>>public function __call() {
  >>>}
  >>>  }

The implement and syntax see:
 https://github.com/chopins/php-src/blob/fast_grammar/FastSyntax.md


Regards

Chopin Xiao
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] NULL Coercion Consistency

[Larry Garfield]

On Mon, Apr 25, 2022, at 4:07 PM, Rowan Tommins wrote:

> Off the top of my head, I don't know what other inconsistencies remain, 
> but my point was that in every case so far, internal functions have been 
> adapted to match userland, not vice versa.



Internal functions error if you pass excessive arguments to a non-variadic 
function.  User-space functions just ignore the extras.  This is an 
inconsistency that has caused me considerable grief in the past year.

I know Joe has said he wants userspace to become more strict like internal on 
this one.  I will not predict what actually happens.



--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] NULL Coercion Consistency

[Rowan Tommins]

On 25/04/2022 10:33, Craig Francis wrote:


The fact that internal functions have parameter parsing behaviour that is 
almost impossible to implement in userland, and often not even consistent 
between functions, is a wart of engine internals, not a design decision.

Bit of a tangent, but do you have some examples? would be nice to clean some of 
these up, or at least have them in mind as we discuss this RFC.



Fundamentally, the internal parameter handling system (ZPP) is 
completely separate from the way function signatures work in userland, 
and evolved based on a different set of requirements. The emphasis of 
ZPP is on unwrapping zval structs to values that can be manipulated 
directly in C; so, for instance, it has always had support for integer 
parameters. Since 7.0, userland signatures have evolved an essentially 
parallel set of features with an emphasis on designing a consistent and 
useful dynamic typing system.


Increasingly, ZPP is being aligned with the userland language, which 
also allows reflection information to be generated based on PHP stubs. 
For instance:


* Making rejected parameters throw TypeError rather than raise a Warning 
and return null
* Giving optional parameters an explicit default in the signature rather 
than inspecting the argument count

* Using union types, rather than ad hoc if/switch on zval type

The currently proposed change to how internal functions handle nulls in 
9.0 is just another part of that process - the userland behaviour is 
well-established, and we're making the ZPP behaviour match.


Off the top of my head, I don't know what other inconsistencies remain, 
but my point was that in every case so far, internal functions have been 
adapted to match userland, not vice versa.




So I'll spend 1 more... I think it's fair to say that developers using 
`strict_types=1` are more likely to be using static analysis; and if 
`strict_types=1` is going to eventually disappear, those developers won't lose 
any functionality with the stricter checking being done by static analysis, 
which can check all possible variable types (more reliable than runtime), and 
(with the appropriate level of strictness) static analysis can do things like 
rejecting the string '5' being passed to an integer parameter and null being 
passed to a non-nullable parameter.



There's an unhelpful implication here, and in your discussion of 
testing, that PHP users can be divided into two camps: those who check 
program correctness with static analysis tools, unit tests, etc; and 
those who don't care about program correctness.


Instead, how about we think about those who are writing new code and 
want PHP to tell them early when they do something silly; and those who 
are maintaining large code bases and have to deal with compatibility 
problems. Neither of these groups is helped enough by static analysers - 
as you've rightly pointed out elsewhere, static checks are *not* 
reliable in a dynamic language, and are not likely to be built-in any 
time soon.


I'm by no means the strongest advocate of strictness in PHP - I think 
there is a risk of throwing out good features with the bad. But I would 
love to see strict_types=1 become unnecessary - not because "everyone's 
running static analysers anyway, so who cares" but because the default 
behaviour provides a good balance of safety and usability.


That makes me very hesitant to use the strict_types modes as a crutch 
for this compatibility break - it only puts off the question of what we 
think the sensible behaviour actually is.




Thank you; and you're right, if you write new code today, you could do that, 
but that assumes you don't need to tell the difference between an empty value 
vs a missing value



As I've said multiple times now, as soon as you pass it to a function 
that doesn't have specific handling for nulls, you lose that distinction 
anyway. There is literally zero difference in behaviour between "$foo = 
htmlspecialchars($_GET['foo'] ?? null)" and "$foo = 
htmlspecialchars($_GET['foo'] ?? '')".


Telling users when they've passed null to a non-nullable parameter is 
precisely about *preserving* that distinction: if you want null to mean 
something specific, treating it as a string is a bug.




But, updating existing code, while that would make automated updates easier, it's likely 
to cause problems, because you're editing the value source, with no idea about checks 
later on (like your example which looks for NULL)... and that's why an automated update 
of existing code would have more luck updating the sinks rather than the sources (e.g. it 
knows which sinks are expecting a string, so it can add in a `strval($var)`, or `(string) 
$var`, or `$var ?? ""`).



That's a fair point, although "sinks" are often themselves the next 
"source", which is what makes static analysis possible as often as it is.



Despite all of the above, I am honestly torn on this issue. It is a 
disruptive change, and I'm not a fan of 

Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion

[Rowan Tommins]

On 21/04/2022 22:45, Mark Randall wrote:

Internals,

I have now opened voting on Undefined Property Error Promotion.

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



In case anyone missed it due to some messed-up mail headers, the thread 
I intended to be a reply to this is here: 
https://externals.io/message/117571


My position is that both this and the undefined variable RFC should have 
been a review of functionality, not a blind copy and paste of Warnings 
into Errors. Since I don't seem to have persuaded anyone else of this, I 
will try to raise one or more follow-up RFCs trying to fill in the gaps.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Readonly Classes

[Máté Kocsis]

Hi Thomas,

The attribute #[AllowDynamicProperties] should not be allowed for
> readonly classes.
>

 Nice catch and I do agree with you, so I will add this restriction.

Máté

Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion

[Guilliam Xavier]

> > Are you proposing to deprecate the implicit `= null` default initializer
> > for untyped properties?
>
> Yes.
>
>
> > Thanks for the recap. For untyped properties, that's the historical
> > behavior. For typed properties, that's explained in
> >
> https://wiki.php.net/rfc/typed_properties_v2#uninitialized_and_unset_properties
> > *. What's the issue?
>
> The issue is that for new users, saying "that's the historical
> behaviour, you just have to learn it" is not very helpful.
>
>
> > * "If a typed property is `unset()`, then it returns to the uninitialized
> > state. While we would love to remove support for the unsetting of
> > properties, this functionality is currently used for lazy initialization
> by
> > Doctrine, in combination with the functionality described in the
> following
> > section."
>
> I think both you and Mark misunderstood my point in bringing this up -
> I'm not complaining about the ability to call unset(), I'm complaining
> that it behaves differently depending how the property was declared.
>
> Look at how the untyped property behaves in this example:
> https://3v4l.org/nClNs The property disappears from var_dump(), but is
> not actually deleted from the object, as seen by it still being private
> when assigned a new value. Given that we have the magic "uninitialized"
> state, and we're proposing to make reading an unset property an error,
> it would make more sense for it to show as '["untyped":"Foo":private] =>
> uninitialized(mixed)'
>

Understood (also https://3v4l.org/DgXJl ). Maybe start a new thread? (this
one is not shown on externals.io, only findable via search)

-- 
Guilliam Xavier

Re: [PHP-DEV] MySQLi Execute Query RFC

[Guilliam Xavier]

On Mon, Apr 25, 2022 at 1:05 PM Craig Francis 
wrote:

> On 22 Apr 2022, at 13:09, Guilliam Xavier 
> wrote:
>
> > https://wiki.php.net/rfc/mysqli_execute_query
>
> Thanks. Maybe add (or even start with) an example of mysqli_query(), to
> show how "migrating to safer" would become easier? retro-fitting your
> example of parameterised query:
>
>
>
>
> Thanks Guilliam, that's a good idea.
>
> To keep it short, I've gone with a more traditional use of
> `$db->real_escape_string()` with string concatenation, including a
> classic mistake with missing quotes around integer values :-)
>
> I do like your example with `vsprintf()`, but I needed to replace the "?"
> with "%s" as well, with made it look more complicated than pre-8.1 prepared
> statements, I hope that's ok.
>

Of course that's "ok", you own your RFC ;) I had suggested [v]sprintf for
brevity and similarity with your parameterised query examples and
https://www.php.net/manual/en/mysqli.real-escape-string.php#refsect1-mysqli.real-escape-string-examples
too, but concatenation is probably more "realistic" anyway...

-- 
Guilliam Xavier

Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion

[Rowan Tommins]

On 25/04/2022 12:24, Guilliam Xavier wrote:

Hi Rowan,

(...) Also, there's this non-standard class called

"stdClass", which unlike standard classes, you can read and write any
property you like without declaring it,


Better reordered "write and read" I think. Yes, like associative arrays,
stdClass is "dynamic" by design.



Indeed, and if that was the only exception, it would be reasonable; it's 
when you pile it on top of all the other rules that it starts making 
people sad.




and even if you use unset(),
you'll never get an error.


That's not true, e.g. given `$o = (object)['foo' => 1]; $o->bar = 2;` then
`unset($o->foo, $o->bar);`, trying to read `$o->foo` or `$o->bar` will both
cause an error (like for `$o->qux`); or I'm misunderstanding you?



You're right, I was mis-remembering; the RFC explicitly says that this 
will error.




Are you proposing to deprecate the implicit `= null` default initializer
for untyped properties?



Yes.




Thanks for the recap. For untyped properties, that's the historical
behavior. For typed properties, that's explained in
https://wiki.php.net/rfc/typed_properties_v2#uninitialized_and_unset_properties
*. What's the issue?



The issue is that for new users, saying "that's the historical 
behaviour, you just have to learn it" is not very helpful.




* "If a typed property is `unset()`, then it returns to the uninitialized
state. While we would love to remove support for the unsetting of
properties, this functionality is currently used for lazy initialization by
Doctrine, in combination with the functionality described in the following
section."



I think both you and Mark misunderstood my point in bringing this up - 
I'm not complaining about the ability to call unset(), I'm complaining 
that it behaves differently depending how the property was declared.


Look at how the untyped property behaves in this example: 
https://3v4l.org/nClNs The property disappears from var_dump(), but is 
not actually deleted from the object, as seen by it still being private 
when assigned a new value. Given that we have the magic "uninitialized" 
state, and we're proposing to make reading an unset property an error, 
it would make more sense for it to show as '["untyped":"Foo":private] => 
uninitialized(mixed)'



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Readonly Classes

[Thomas Gutbier]

Am 19.04.2022 um 09:58 schrieb Máté Kocsis:

Hi Everyone,

After quite a long pause, I'd like to revive the discussion of readonly
classes and possibly put it to vote in the coming week(s).

If I'm following, then this RFC is about 90% syntactic sugar for putting

`readonly` on all properties, plus disabling dynamic properties.  That's
the long-and-short of it, yes?

Yes, exactly!


Should this rfc (https://wiki.php.net/rfc/deprecate_dynamic_properties) 
be considered here?


The attribute #[AllowDynamicProperties] should not be allowed for 
readonly classes.


Thomas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: LOCK_SH for file_get_contents ?

[Guilliam Xavier]

First, hello...

> This has been requested for years (since at least 2009?) but it seems no
> > actual plan has been proposed
> > How about this?
> > since we already have the constant FILE_USE_INCLUDE_PATH , seems it was
> > introduced in PHP5.0.0,
> >
> > 1: FILE_USE_INCLUDE_PATH currently collides with LOCK_SH (they're both
> 1),
> > lets change FILE_USE_INCLUDE_PATH to something that doesn't collide with
> > any of LOCK_SH | LOCK_EX | LOCK_NB
> > for example  (1 << 3) / int(8)
> > 2: change argument #2 from "bool $use_include_path = false" to "int|bool
> > $flags = 0" , treating bool(false) the same as int(0) and bool(true) the
> > same as FILE_USE_INCLUDE_PATH , and support LOCK_SH | LOCK_NB |
> > FILE_USE_INCLUDE_PATH here
> > (i think LOCK_EX could also be supported, but that might be
> controversial,
> > and the use case is certainly limited, if there is one at all)
> >
> > because it's kind of silly, and at times annoying, that file_put_contents
> > support LOCK_EX but file_get_contents does not support LOCK_SH
>
> can we at least change FILE_USE_INCLUDE_PATH to 8 / (1<<3)  ? that would
> allow a userland implementation of file_get_contents to support LOCK_SH and
> FILE_USE_INCLUDE_PATH
>
> The current situation is so bad that FILE_USE_INCLUDE_PATH literally cannot
> be used in strict_mode=1, it's pretty much completely useless since php
> 7.0, so I doubt it'll break anything keeping up with new releases of PHP.


After some search, I assume you're referring to
https://bugs.php.net/bug.php?id=47115 (Request #47115 Can't use flag
LOCK_SH in file_get_contents "similar to file_put_contents can use
LOCK_EX"). I'm more "empathetic" to that than with your mails alone.
Anyway, I doubt FILE_USE_INCLUDE_PATH can be changed to 8, because that's
already FILE_APPEND (and both can be used with file_put_contents()). Here's
the current (PHP 8.1, unchanged since at least 5.6) var_export() of
`array_filter(get_defined_constants(), function ($k) { return
preg_match('/^(FILE|LOCK)_/', $k); }, ARRAY_FILTER_USE_KEY)`:

```
array (
  'LOCK_SH' => 1,
  'LOCK_EX' => 2,
  'LOCK_UN' => 3,
  'LOCK_NB' => 4,
  'FILE_USE_INCLUDE_PATH' => 1,
  'FILE_IGNORE_NEW_LINES' => 2,
  'FILE_SKIP_EMPTY_LINES' => 4,
  'FILE_APPEND' => 8,
  'FILE_NO_DEFAULT_CONTEXT' => 16,
  'FILE_TEXT' => 0,
  'FILE_BINARY' => 0,
)
```

(ignore the last two). Actually it almost looks like it's only "by chance"
that file_put_contents() can use LOCK_EX (2 i.e. 1<<1) together with
FILE_USE_INCLUDE_PATH (1 i.e. 1<<0) and FILE_APPEND (8 i.e. 1<<3)...

That said, [I don't think LOCK_SH = 1 can be changed, but] maybe
FILE_USE_INCLUDE_PATH can be changed to e.g. 32, along with your suggestion
2 (change argument #2 [of file_get_contents()] from `bool $use_include_path
= false` to `int|bool $flags = 0` [*but*] treating `true` like
FILE_USE_INCLUDE_PATH [*rather than 1 i.e. LOCK_SH*] [note sure about
LOCK_NB though])?

(PS: there's also **file()**, which currently supports
FILE_USE_INCLUDE_PATH, FILE_IGNORE_NEW_LINES and FILE_SKIP_EMPTY_LINES...)

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] Discussion before submission of array_transpose() RFC

[mickmackusa]

On Sun, Apr 24, 2022 at 10:24 PM Rowan Tommins  wrote:
>
> On 23/04/2022 23:42, mickmackusa wrote:
> > Ideally, PHP should have a native transposing function to put
> > developers out of their misery -- much like array_key_last() did.
>
>
> I think a better comparison would be array_column -
> https://wiki.php.net/rfc/array_column One interesting thing that Ben
> Ramsey wrote alongside that RFC was a pure PHP implementation with
> identical behaviour, available for use as a polyfill:
> https://github.com/ramsey/array_column
>
> Unlike array_column, I don't recall personally needing an
> array_transpose function, but am willing to believe that many people do.
>
>
> My first piece of advice would be to start with a definition of what you
> mean by "transpose" in this context, with an example of input and output
> in the basic case, and then a few scenarios where it's useful.
>
> Having that clear would then help understand the details you go into,
> each of which could be accompanied by its own example. For instance:
>
>
> > Let's create an intuitive transposing function for data sets with a
> > minimum depth of 2 levels.
>
>
> I can't picture what "transpose" means for something with more than 2
> levels.
>
>
> > As a matter of flexibility, there should be no requirement that the
> > lone parameter be a matrix or dense data structure.
>
>
> I have no idea what this means.
>
>
> > It should also preserve keys to give it a clear advantage over
> > pre-existing functional techniques.
>
>
> Preserve what keys?
>
>
> >  // [['single' => 'row']] becomes ['single' => 'row'] but should be
> > ['single' => ['row']]
>
>
> Should it? Why?
>
>
> My second piece of advice is to remember that flexibility, ease of use,
> and efficiency, are three corners of a triangle, and you can't optimise
> for all three. array_column does a reasonable job of covering multiple
> use cases, but there have been several unsuccessful requests over the
> years to enhance it or create variations for other use cases, so you're
> never going to make everyone happy.
>
>
> > Should the function unconditionally return an array of arrays?
> > Should it preserve the initial data types of the first and second level?
> > Should data type preservation be excluded to increase the chances of
> > its implementation?
> > [...]
> >  1. Unconditionally cast output as array of arrays.
> > [...]
> >  2. Preserve original data types of level one and level two.
> > https://3v4l.org/RRKlr
> >
> > (If input is two dimensional, then the first occurring data type in
> > the second level will dictate the result's first level data type.)
> > [...]
> > If only initially implemented to return an array of arrays, then
> > expanding the result data types in the future may be of interest.
>
>
> Without really understanding what you're saying, my suspicion is that
> these paragraphs are trying too hard to make a Swiss-army knife rather
> than a sharp blade.
>
>
> > List of Stack Overflow pages which seek to implement transposition
>
>
> Would all of these requirements be satisfied by the same implementation,
> without needing a complex set of options? What can we learn from the
> links about what features are likely to be most useful to people?
>
>
> I look forward to seeing a draft RFC, which can take the time to explain
> the features you think are needed.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>

Thanks for the feedback, Rowan.  Here are some answers and thoughts...

The basic premise of transposition is to replace the first level keys
with the second level keys.
This can be visualized as converting columns of data into rows of data.

With:

A B C
D E F
G H I

the expected result is:

A D G
B E H
C F I

When dealing with an indexed array of indexed arrays with more than
one row, `array_map(null, ...$array)` is a beautiful, concise
technique.
However, an array with a single row returns an unexpected structure,
and associative arrays and objects cause trouble.
Using nested foreach loops is reliable, but is less elegant, requires
multiple temporary variables, certainly more verbose, and must be
wrapped in a custom function for functional-style coding.

Like array_column()'s ability to respect object data, I felt it might
be beneficial to allow/respect objects with this function proposal.
I've made a judgment call to swap the data types of the first level
with the second level, but perhaps data types should be honored, yet
not swapped.
With my type-preserving implementation, an array of objects will
become an object of arrays.
Perhaps an array of objects should remain an array of objects after
transposition?
I'm open to feedback on this behavior.
If there is no support for any type preservation (swiss army knife)
and the function should unconditionally return an array of arrays,
then it will improve performance to use the "basic" implementation for
the RFC.
I don't program in C so I don't know if there are any optimizations
that can be enjoyed.

[PHP-DEV] PHP 8.2 Release Manager Selection

[Sergey Panteleev]

Hi all,

Lately I've been doing documentation for PHP, keeping the Russian version up to 
date, and helping a little with the English, German and French versions.

I would also like to contribute and help in other areas, such as newbie RM.

If possible, my hat is in the ring.

—
wbr,
Sergey Panteleev

[PHP-DEV] PHP 8.2 Release Manager Selection

[Christoph M. Becker]

Hi all,

with the first alpha of PHP 8.2 due in 6 weeks (unless we are going to
change our usual schedule), I think it's time to start the process of
finding and electing release managers for the next minor release of PHP.

We are looking for two souls to take on this role.  Whomsoever is
elected will be guided and helped by the current, as well as previous
RMs and the excellent documentation in release-process.md[1].

Candidates should have a reasonable knowledge of internals (without
necessarily being a C guru), be confident about merging pull requests
without breaking backward compatibility, doing triage for bugs,
liaising with previous release managers, and generally getting the
branch in good shape, as these are among the activities you will be
undertaking as release manager.

Notably, at least one of the volunteers must be a "veteran" release
manager meaning they have participated in at least one release of PHP in
the past.  The other may be an additional veteran, or more ideally,
someone new to the RM role (in order to increase our supply of veteran RMs).

Please put your name forward here if you wish to be considered a
candidate.  An initial TODO page has been added to the wiki and contains
provisional dates for GA and pre-releases[2].

[1] 
[2] 

--
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion

[Guilliam Xavier]

Hi Rowan,

(...) Also, there's this non-standard class called
> "stdClass", which unlike standard classes, you can read and write any
> property you like without declaring it,


Better reordered "write and read" I think. Yes, like associative arrays,
stdClass is "dynamic" by design.


> and even if you use unset(),
> you'll never get an error.
>

That's not true, e.g. given `$o = (object)['foo' => 1]; $o->bar = 2;` then
`unset($o->foo, $o->bar);`, trying to read `$o->foo` or `$o->bar` will both
cause an error (like for `$o->qux`); or I'm misunderstanding you?

> You could special case nullable, but then it's an extra rule to learn
> > beyond "typed = needs to be initialized".
>
> I'm more inclined to the opposite: if reading an "undefined" property is
> going to be an error, maybe reading an "uninitialized" one should be
> too, even if you don't declare a type for it.
>

Are you proposing to deprecate the implicit `= null` default initializer
for untyped properties?


> And maybe we should think about exactly what unset() means, and which
> error you're going to get after you use it - is the property "undefined"
> or "uninitialized"? Currently, an untyped property becomes "undefined",
> as though it never existed; but a typed property is still on the object,
> but "uninitialized". Yet either way, assigning a new value brings back
> the declared property, not a dynamic one with the same name:
> https://3v4l.org/nClNs
>

Thanks for the recap. For untyped properties, that's the historical
behavior. For typed properties, that's explained in
https://wiki.php.net/rfc/typed_properties_v2#uninitialized_and_unset_properties
*. What's the issue?

* "If a typed property is `unset()`, then it returns to the uninitialized
state. While we would love to remove support for the unsetting of
properties, this functionality is currently used for lazy initialization by
Doctrine, in combination with the functionality described in the following
section."

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] MySQLi Execute Query RFC

[Craig Francis]

On 22 Apr 2022, at 13:09, Guilliam Xavier  wrote:
> > https://wiki.php.net/rfc/mysqli_execute_query 
> > 
> 
> Thanks. Maybe add (or even start with) an example of mysqli_query(), to show 
> how "migrating to safer" would become easier? retro-fitting your example of 
> parameterised query:



Thanks Guilliam, that's a good idea.

To keep it short, I've gone with a more traditional use of 
`$db->real_escape_string()` with string concatenation, including a classic 
mistake with missing quotes around integer values :-)

I do like your example with `vsprintf()`, but I needed to replace the "?" with 
"%s" as well, with made it look more complicated than pre-8.1 prepared 
statements, I hope that's ok.

Craig

Re: [PHP-DEV] NULL Coercion Consistency

[Craig Francis]

On 25 Apr 2022, at 11:35, Rowan Tommins  wrote:
> Taking time to find and make fixes is the whole point of deprecation notices 
> - if nothing else changes, they can expect to have another 3.5 years before a 
> version of PHP is released where these become errors. Upgrading to PHP 8.1 as 
> soon as possible but only tackling the deprecations when time allows is 
> absolutely the right thing to do.


That's true for things that need to be fixed, like the deprecation and removal 
of magic quotes, but this is a lot of work for... I can't provide an answer to 
that.

In the mean time, I've only convinced 3 teams to upgrade to 8.1, and two of 
them are using `set_error_handler()` to specifically ignore this error (the log 
files were filled with far too many "passing null to parameter" deprecation 
messages, whereas adding #[ReturnTypeWillChange] wasn't too bad).

Craig

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] NULL Coercion Consistency

[Rowan Tommins]

On 25/04/2022 10:44, Craig Francis wrote:

You're right, I am working with a few development teams that are simply not 
upgrading to 8.1 at the moment, they don't have the time to fix this issue... 
two are using set_error_handler() to ignore this specific deprecation notice, 
and one team has moved over, but they are still finding these issues ~6 months 
later.



Taking time to find and make fixes is the whole point of deprecation 
notices - if nothing else changes, they can expect to have another 3.5 
years before a version of PHP is released where these become errors. 
Upgrading to PHP 8.1 as soon as possible but only tackling the 
deprecations when time allows is absolutely the right thing to do.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] NULL Coercion Consistency

[Craig Francis]

> On 21 Apr 2022, at 17:32, Andreas Leathley  wrote:
> 
>>> There is another 3.5 years until PHP 9 is likely to come out, which is a 
>>> lot of time for people to adjust their codebase. I could even see an 
>>> argument for not promoting it to a fatal error in 9.0 if so many people 
>>> need more time.
>> 
>> 
>> If it's deprecated, that is an intent to break... and if no other solutions 
>> present themselves, and the vote for this RFC fails... why would it be 
>> delayed? It will then be clear the Internals developers want this (they 
>> would have made an informed choice, and put their name to it).
> 
> A deprecation notice is fairly harmless. If in two years many projects and 
> many developers say that they need more time to fix these deprecations and 
> promoting them to errors would cause a lot of problems, then it would be easy 
> to prolong the period where it is only a deprecation with a small RFC. By 
> then more people will know if they are impacted, many frameworks will have 
> updated, and there will be a clearer picture if this is such a big deal or 
> not. Right now this is not clear - I doubt most projects are using PHP 8.1, 
> not even all frameworks/libraries are compatible to PHP 8.1.


You're right, I am working with a few development teams that are simply not 
upgrading to 8.1 at the moment, they don't have the time to fix this issue... 
two are using set_error_handler() to ignore this specific deprecation notice, 
and one team has moved over, but they are still finding these issues ~6 months 
later.



>> Are you going to suggest any improvements? what have I missed? I'm trying to 
>> keep it short, because I know long RFC's can be a problem.
> 
> An RFC should cover the discussions held on this mailing list. From the RFC 
> howto:
> 
> "Update your RFC to document all the issues and discussions. Cover both the 
> positive and negative arguments."
> 
> Do you honestly believe you have done that? I have tried to discuss some 
> counterpoints and alternatives to your proposal, but none are mentioned in 
> the RFC. I also don't see the discussion points of other people in the RFC. 
> None of the alternatives to your proposal are mentioned in the RFC - like 
> changing the internal functions to accept null instead. There have been quite 
> a few suggestions and arguments made so far, and I don't see them in the RFC.


I'll ask again, what have I missed? as in, please, give me details.

Last time you vaguely said that "George Peter Banyard wrote some extensive 
arguments", I spent at least an hour going though every single point (again), 
and this time I listed them out for you, and you ignored that, not even an 
apology.

The only point you made in that last paragraph is "changing the internal 
functions to accept null", it's already there, under the heading "Rejected 
Features", which includes the link to the RFC I created, and the reason it was 
rejected. That reason is also noted in the second paragraph of the Introduction.



> I have discussed RFCs with a few people on this mailing list, sometimes with 
> very different opinions about a topic, and not always was there a resolution 
> to the topic at hand. Yet the discussions with you have been the most 
> frustrating so far, because you say you are open to arguments and proposals, 
> yet you do not seem to consider them at all - yet you really seem to believe 
> you are totally open-minded. I have been impressed by a few people on this 
> mailing list who I disagreed with wholeheartedly, because I noticed with how 
> much care they tried to relay disagreeing arguments and other proposals in 
> the RFC and how balanced the RFCs were at the end. Your RFC seems totally 
> incomplete to me and mainly based on your made-up opinion. But at this point 
> I don't think I will get through to you in any way, which is why I will step 
> out of this conversation. If the RFC comes to a vote in the current 
> conditions though I will raise an objection that it does not represent the 
> discussions held on this mailing list and should be disregarded because of 
> that.


I have no idea how to respond to this, I have spent a considerable amount of 
time carefully reading your 5 emails, responding to every single point you 
raised (which you simply ignore), ensuring all points are in my RFC, and this 
is your attitude? no apology, no thanks, just vague complaints and insults?

If you have any objection that is not already noted in the RFC, please, let me 
know what it is... maybe "Andreas does not like the wording in this RFC, or the 
stats provided, but does not provide any alternative"?

Craig

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] NULL Coercion Consistency

[Craig Francis]

On 21 Apr 2022, at 15:09, Rowan Tommins  wrote:
> On Wed, 20 Apr 2022 at 18:02, Craig Francis  wrote:
>> I'm just trying to focus on how PHP has worked
> 
> You keep repeating this mantra, but user-defined functions with declared 
> parameter types have never accepted nulls, in any mode, unless explicitly 
> marked with "?" or "= null".


Thanks Rowan, and you're right that user defined functions haven't worked like 
that, but that's not really what I'm focused on - which is how PHP has always 
worked in regards to internal functions (the bit that has changed, and is 
causing problems), and how NULL coercion works in other contexts.

I mention user defined functions because I still want user and internal 
functions to work in the same way (one form of consistency).



> The fact that internal functions have parameter parsing behaviour that is 
> almost impossible to implement in userland, and often not even consistent 
> between functions, is a wart of engine internals, not a design decision.


Bit of a tangent, but do you have some examples? would be nice to clean some of 
these up, or at least have them in mind as we discuss this RFC.



> All of that, and the "consistency" in the title of your RFC, is a complete 
> distraction from the real questions:
> 
> 1) given a null input, and a non-nullable parameter, what should the run-time 
> do?
> 2) what is the best way to help users update their code to be compatible with 
> that new behaviour?


I'm happy to change the title, but consistency does apply in different ways... 
as in, ensuring user and internal function parameters work in the same way 
(even if that way might need to change slightly); how other simple values like 
string/int/float/bool values can still be coerced for parameters, but NULL 
won't be; and how NULL coercion does work in other contexts (string contact, 
`==` comparison, sprintf, print, array keys).

To answer your questions,

1. I think NULL inputs should be coerced for non-nullable parameters, when not 
using `strict_types=1`, and where static analysis tools provide the 
additional/stricter checks (like how they can reject a string '5' for an 
integer parameter). With nullable parameters being different by accepting NULL 
without coercion.

2. With this approach, developers won't need to update their code... in 
contrast, the approach of NULL causing a Type Error for internal functions, 
developers will need to change their code, and I cannot find any tools that 
help with this, except very strict static analysis to find but not update them 
(it's difficult tracing every variable from source to sink).



>> Agreed, the only thing I'd add... failing early with NULL might help debug 
>> some problems (assuming there is a problem), but I believe static analysis 
>> and unit tests are much better at doing this (e.g. static analysis is able 
>> to see if a variable can be NULL, and apply those stricter checks, as noted 
>> by George with Girgias RFC).
> 
> 
> I think we should institute a "swear jar" - whenever someone says "static 
> analysis could do this better", they have to donate €1 to the PHP Foundation. 
> :P


Cool, I've got 23 credits left this month :-)

So I'll spend 1 more... I think it's fair to say that developers using 
`strict_types=1` are more likely to be using static analysis; and if 
`strict_types=1` is going to eventually disappear, those developers won't lose 
any functionality with the stricter checking being done by static analysis, 
which can check all possible variable types (more reliable than runtime), and 
(with the appropriate level of strictness) static analysis can do things like 
rejecting the string '5' being passed to an integer parameter and null being 
passed to a non-nullable parameter.



> More seriously, 1) your own RFC claims that fewer than 33% of developers use 
> static analysis; and 2) if PHP had a compile step with mandatory static 
> analysis, we would still have to decide whether passing NULL to these 
> functions should be rejected as an error by the static analyser.


Not sure how to respond to that... do you think PHP will have a compile step, 
with mandatory static analysis? Considering how static analysis tools today 
have several levels, and the ability to create a baseline (to ignore problems 
with old code), are you suggesting that everyone would have the strictest 
checks enabled, where no coercion happens at all?




>> In contrast, failing early at runtime, on something that is not actually a 
>> problem, like the examples in my RFC, creates 2 problems (primarily 
>> upgrading; but also adding unnecessary code to explicitly cast those 
>> possible NULL values to the correct type, which isn't needed for the other 
>> scalar types).
> 
> 
> I've been trying not to nit-pick, because I think over-all you do have a 
> valid point, but several of your examples do not need any extra code to 
> handle nulls; and those that do need maybe a handful of characters. For 
> instance, 

[PHP-DEV] Re: [RFC] [Discussion] Readonly Classes

[Máté Kocsis]

Hi Internals,

As there's not much discussion, I will start voting on Wednesday.

Cheers,
Máté