Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
Replying in one long email to all three who replied to me: > On Jul 5, 2021, at 8:03 AM, Guilliam Xavier wrote: > Hi Mike, > > Your links speak *in general*. However this is *specifically for PHP*: > https://www.php.net/manual/en/errorfunc.constants.php#errorfunc.constants.errorlevels.e-deprecated-error > (*emphasis* mine) > > E_DEPRECATED: Run-time notices. Enable this to receive warnings about > code that *will not work in future versions*. 1. In general (no pun intended), is it a good idea for PHP to take a general concept and redefine its meaning? (Rhetorical question.) 2. That link you provided speaks of not working in future versions. That future version could be 5 major versions from now, doesn't have to be next version. 3. And most importantly, the content on that page is not written in immutable stone. It could just as easily be updated to say the following, assuming that an agreement is made to do so: "Enable this to receive warnings about code constructs that are discouraged and MAY not work in future versions, so best for developers to no longer depend on it." > As for "significant BC breakage", isn't that what major versions are for? > (and with the current release plan, 9.0 would be for end 2025, i.e. 4 years > after 8.1) They can be, but AFAIK there is no immutable principle in software that deprecated versions must be removed in the next major version. Doing so or not doing is simply a choice, a decision about what is in the best interest of the software and its user base. And unless I misunderstand, nothing about the PHP project is immutable that cannot be changed by consensus and/or an RFC vote. So I am simply making the argument that this restrictive idea that deprecations *must* result in removal in the next major version can do more harm than good in selected cases. Being restrictive in our view of deprecation means we create BC-breaked changes when we really don't have to, and more importantly it means we do not signal that certain practices are to be discouraged when we could. Imagine if we decided to deprecated global variables and instead encourage DI and/or static variables in classes? IF we could deprecate global without removal, I would be 100% for deprecating global. But given the current restrictive interpretation promoted by some, we should all be 0% for deprecating global. > On Jul 5, 2021, at 8:05 AM, G. P. B. wrote: > > For the PHP project deprecation means a future removal, I'm pretty sure this > is an agreed policy for the project. Can you point me to where this has been definitely agreed in the past? An RFC ideally? (Honest question.) There is this[1] but it only says functions will usually be completely removed "Later" and not "next major version." "Later" could be 5 versions later. There is this[2], but it makes no mention of when, nor was it ever voted on. [1] https://wiki.php.net/rfc/deprecated-modifier [2] https://wiki.php.net/rfc/deprecated_attribute > E_STRICT was like Rowan said used for cases of "well you should probably not > do this but we'll accept it", > and this category has been removed. But the E_STRICT constant was not removed. (Ironically?) The motivation was "to simplify our error model and resolve the currently unclear role of strict standards notices." So as I read it[3] we are talking apples (policy) and oranges (simplify error model/improve clarity) [3] https://wiki.php.net/rfc/reclassify_e_strict > Now if you truly want this definition of "deprecation" can I bring forward > again to "deprecate" short tags, using 'var' for object properties, all of > the SPL data structures, a bunch of extensions, using locales, and maybe to > be fancy emit one when you don't use a visibility modifier on object > methods/properties/constants, heck why not even one for not using a typed > property now that we got mixed and union types. I would be 1000% for ALL of those. Bring them on, PLEASE. But since you wrote that I assume you think that would be a bad idea. Why? > As you can see this opens the door to kinda everything being marked as > deprecated just to ensure another discussion needs to be held for a removal. Yes, it opens the door for doing a lot of good for PHP, IMO. > The policy of X being deprecated means it's going to be removed is very clear > for end users who don't need to scramble as to whether or not this > deprecation leads to a removal or not. In all my years working with other developers, I have never witnessed anyone "scramble" to determine if deprecation means removal. Deprecation has a pretty clear meaning to most developers I know. It simply means "not recommended." If a developer uses a deprecated feature, they are "doing it wrong." BUT, the project owner who has existing code isn't doing it wrong to want to continue to run their software without having to invest new money into refactoring because of a function removal. Unless there is a
[PHP-DEV] [RFC] [VOTE] is_literal
Hi Internals, I have opened voting on https://wiki.php.net/rfc/is_literal for the is-literal function. The vote closes 2021-07-19 The proposal is to add the function is_literal(), a simple way to identify if a string was written by a developer, removing the risk of a variable containing an Injection Vulnerability. This implementation is for literal strings ONLY (after discussion over allowing integers) and, thanks to the amazing work of Joe Watkins, now works fully with compiler optimisations, interned strings etc. Craig
Re: [PHP-DEV] [RFC] Pipe Operator, take 2
On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote: > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote: > > Hi folks. Me again. > > > > A year ago, I posted an RFC for a pipe operator, |>, aka function > > concatenation. At the time, the main thrust of the feedback was "cool, > > like, but we need partial function application first so that the syntax > > for callables isn't so crappy." > > > > The PFA RFC is winding down now and is looking quite good, so it's time > > to revisit pipes. > > > > https://wiki.php.net/rfc/pipe-operator-v2 > > > > Nothing radical has changed in the proposal since last year. I have > > updated it against the latest master. I also updated the RFC to use > > more examples that assume PFA, as the result is legit much nicer. i > > also tested it locally with a combined partials-and-pipes branch to > > make sure they play nicely together, and they do. (Yay!) Assuming PFA > > passes I will include those tests in the pipes branch before this one > > goes to a vote. > > Hi again. > > With PFA being declined, I've again reworked the Pipes RFC. > > 1) It now does not use PFA in any examples, but it does use Nikita's > first-class-callables RFC that looks like it's going to pass easily. > > 2) With major hand-holding from Levi Morrison and Joe Watkins, the > implementation has shifted a bit. It now evaluates left-to-right, > always, whereas the previous version evaluated right-to-left. That is, > instead of $a |> $b |> $c desugaring into $c($b($a)), it now becomes > effectively $tmp = $a; $tmp = $b($tmp); $tmp = $c($tmp); That matters > if $b or $c are function calls that return a callable, as they are then > only called when the pipeline gets to that part of the expression. (If > all the functions involved are pure functions, then it doesn't make a > difference in practice.) > > 3) I included references to several existing PHP libraries that > implement similar logic, in mostly complex and ugly ways. > > 4) Of note, Brent posted a Twitter poll last week about pipes, and the > response was overwhelmingly in favor. > (https://twitter.com/brendt_gd/status/1408271132650885123) Naturally a > Twitter poll is extremely unscientific, but I think between the > existing libraries and the response there the answer to the question > "is there actually a demand for this feature?" is unquestionably yes. > > 5) Examples have been reworked to be a bit prettier. > > 6) Added another language reference that has a pipe operator that works > basically like described here. (OCaml) > > I am planning to take this version of the RFC to a vote on Monday or > Tuesday, as Tuesday is the last day possible to start a vote for 8.1 > features. > > --Larry Garfield Based on feedback on the PR, I've updated the RFC to forbid functions that pass or return by reference. They're not really useful in pipes at all, and were only supported before because the implementation happened to allow it. The PR hasn't been updated for that yet, but I figure that's easy enough to update post-vote if it passes. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] First-class callable syntax
On 05/07/2021 15:35, Nikita Popov wrote:
The actual echo syntax is echo "Foo". PHP allows you to write echo("Foo")
in the same way it allows you to write echo("Foo"). Don't do it :)
Indeed. Note that this is valid:
echo "hello", " ", "world";
But this is not:
echo("hello", " ", "world");
I have in the past had a bug make it into production because the
parentheses around a call to "include" were mis-placed because of this
incorrect belief that it is "function-like":
if ( include('some_file.php') && bar() )
Is equivalent to this (will always run bar(), then attempt to include
either (string)true or (string)false):
if ( include ('some_file.php' && bar()) )
When what was intended was this:
if ( (include 'some_file.php') && bar() )
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] First-class callable syntax
On Mon, Jul 5, 2021 at 4:14 PM Sara Golemon wrote:
> On Fri, Jul 2, 2021 at 5:51 AM Nikita Popov wrote:
>
>> As the partial function application RFC has not been accepted, I have
>> opened voting on https://wiki.php.net/rfc/first_class_callable_syntax.
>> The
>> vote closes on 2021-07-16.
>>
>> This RFC uses a syntax that is forward-compatible with partial function
>> application. Should it not be accepted, I'll explore alternative syntax
>> possibilities.
>>
>>
> Was replying to a comment on reddit which made me look closer at your
> implementation. It looks like this does NOT allow for use of function-like
> language constructs.
> e.g. $e = echo(...); $p = print(...); $r = require(...); // etc...
>
> 1/ Is this intentional?
>
Yes.
> 2/ Is this actually a good thing?
>
Yes. echo is not a function, so you can't acquire a callable to it.
The actual echo syntax is echo "Foo". PHP allows you to write echo("Foo")
in the same way it allows you to write echo("Foo"). Don't do it :)
Regards,
Nikita
Re: [PHP-DEV] [VOTE] First-class callable syntax
On Fri, Jul 2, 2021 at 5:51 AM Nikita Popov wrote: > As the partial function application RFC has not been accepted, I have > opened voting on https://wiki.php.net/rfc/first_class_callable_syntax. The > vote closes on 2021-07-16. > > This RFC uses a syntax that is forward-compatible with partial function > application. Should it not be accepted, I'll explore alternative syntax > possibilities. > > Was replying to a comment on reddit which made me look closer at your implementation. It looks like this does NOT allow for use of function-like language constructs. e.g. $e = echo(...); $p = print(...); $r = require(...); // etc... 1/ Is this intentional? 2/ Is this actually a good thing? I'm actually of a mind that it's a good thing, as surprising ways to reach eval() are foot-guns waiting to happen, but wanted to get confirmation. -Sara
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
Le lun. 5 juil. 2021 à 13:39, Mike Schinkel a écrit : > > On Jul 5, 2021, at 7:14 AM, Rowan Tommins > wrote: > > > > On 05/07/2021 11:46, Patrick ALLAERT wrote: > >> Did we ever deprecated something without the immediate intention of > >> removing it? > > > > > > What would that even mean? > > It would mean that although the functions are available and allowed, they > are not recommended[1]. > Exactly my point. The fact that it gets deprecated with a notice gets much more visibility than just documentation changes (which I encourage anyway!). > > Surely a deprecation, by definition, is a notice that something is going > to be removed. > > I know that you, and others on this list, have chosen to define > deprecation as including removal, but that is actually not the accepted > definition on the web, nor is it in any way a requirement, it is just your > preference. > > Indirectly from Wikipedia and voted as the top answer on StackOverflow > here[2] (emphasis MINE): > > "deprecation is a status applied to software features to indicate that > they should be avoided, typically because they have been superseded. > Although deprecated features remain in the software, their use may raise > warning messages recommending alternative practices, and deprecation MAY > indicate that the feature will be removed in the future." > > So I am arguing for the legitimacy of retaining "deprecated" features if > their removal would cause significant BC breakage, I'm not just trying to > be a pendant. >
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
On 05/07/2021 12:39, Mike Schinkel wrote: know that you, and others on this list, have chosen to define deprecation as including removal, but that is actually not the accepted definition on the web, nor is it in any way a requirement, it is just your preference. I stand corrected, I had not encountered contexts where it was defined differently. To be clear, I don't think contrasting "accepted definition" against "my preference" is quite right here; there are plenty of places that document the definition I am familiar with, e.g. * Foldoc (taken from the Jargon File): http://foldoc.org/deprecated * Wiktionary: https://en.wiktionary.org/wiki/deprecated Removal is also specifically mentioned in official documentation for plenty of PHP projects, e.g. * The description of the "@deprecated" tag in PhpDocumentor : https://docs.phpdoc.org/3.0/guide/references/phpdoc/tags/deprecated.html * The general migration guide for Symfony : https://symfony.com/doc/current/setup/upgrade_major.html#make-your-code-deprecation-free * The Drupal Core deprecation policy: https://www.drupal.org/about/core/policies/core-change-policies/drupal-core-deprecation-policy More directly relevant, the PHP manual at https://www.php.net/manual/en/errorfunc.constants.php currently describes E_DEPRECATED as: > Run-time notices. Enable this to receive warnings about code that will not work in future versions. Obviously, that could be changed to also include "features that are strongly discouraged but not currently planned for removal", but I'm still not convinced that that would be a useful change. If we can create and document a good alternative for strftime(), then why *not* mark it for future removal. And if we can't provide that alternative, what use is there in notices discouraging it? Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Readonly properties
On Mon, Jul 5, 2021 at 1:56 PM Patrick ALLAERT
wrote:
> Le jeu. 1 juil. 2021 à 12:23, Nikita Popov a
> écrit :
>
>> Hi internals,
>>
>> I have opened voting on https://wiki.php.net/rfc/readonly_properties_v2.
>> The vote closes 2021-07-15.
>>
>> See https://externals.io/message/114729 for the discussion thread on this
>> proposal. I think a decent tl;dr is that readonly properties as proposed
>> do
>> not play well with clone-based withers, so some people believe we should
>> either improve cloning first, or introduce asymmetric property visibility
>> instead, which does not suffer from this issue.
>>
>> Regards,
>> Nikita
>>
>
> With the proposed implementation the following class:
>
> class A {
> public readonly string $name;
>
> public function __construct(string $name) {
> $this->setName($name);
> }
>
> public function setName(string $name) {
> $this->name = $name;
> }
>
> public function setName2(string $name) {
> $this->setName($name);
> }
>
> public function setName3(string $name) {
> $this->name = $name;
> }
> }
>
> Would behave like this:
>
> $a = new A("Initial name");
> echo $a->name, "\n"; // echoes Initial name
>
> $a->setName("New name"); // Allowed ?
> echo $a->name, "\n"; // echoes New name
>
> $a->setName2("Yet another name"); // Allowed ?
> echo $a->name, "\n"; // echoes Yet another name
>
> $a->setName3("Yet another name"); // Not allowed, although identical to
> setName()?
>
> [...]
>
> Is the above behaviour an implementation bug or does the RFC implies that?
>
This is indeed an implementation bug. Thanks for catching it! The issue
here is that the property write gets cached and bypasses the readonly
check, which of course shouldn't be happening.
Regards,
Nikita
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
On Mon, 5 Jul 2021 at 13:39, Mike Schinkel wrote: > > On Jul 5, 2021, at 7:14 AM, Rowan Tommins > wrote: > > > > On 05/07/2021 11:46, Patrick ALLAERT wrote: > >> Did we ever deprecated something without the immediate intention of > >> removing it? > > > > > > What would that even mean? > > It would mean that although the functions are available and allowed, they > are not recommended[1]. > > > > Surely a deprecation, by definition, is a notice that something is going > to be removed. > > I know that you, and others on this list, have chosen to define > deprecation as including removal, but that is actually not the accepted > definition on the web, nor is it in any way a requirement, it is just your > preference. > > Indirectly from Wikipedia and voted as the top answer on StackOverflow > here[2] (emphasis MINE): > > "deprecation is a status applied to software features to indicate that > they should be avoided, typically because they have been superseded. > Although deprecated features remain in the software, their use may raise > warning messages recommending alternative practices, and deprecation MAY > indicate that the feature will be removed in the future." > > So I am arguing for the legitimacy of retaining "deprecated" features if > their removal would cause significant BC breakage, I'm not just trying to > be a pendant. > > -Mike > [1] https://whatis.techtarget.com/definition/deprecated > [2] https://stackoverflow.com/questions/8111774/deprecated-meaning > For the PHP project deprecation means a future removal, I'm pretty sure this is an agreed policy for the project. E_STRICT was like Rowan said used for cases of "well you should probably not do this but we'll accept it", and this category has been removed. Now if you truly want this definition of "deprecation" can I bring forward again to "deprecate" short tags, using 'var' for object properties, all of the SPL data structures, a bunch of extensions, using locales, and maybe to be fancy emit one when you don't use a visibility modifier on object methods/properties/constants, heck why not even one for not using a typed property now that we got mixed and union types. As you can see this opens the door to kinda everything being marked as deprecated just to ensure another discussion needs to be held for a removal. The policy of X being deprecated means it's going to be removed is very clear for end users who don't need to scramble as to whether or not this deprecation leads to a removal or not. Best regards, George P. Banyard
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
On Mon, Jul 5, 2021 at 1:39 PM Mike Schinkel wrote: > > On Jul 5, 2021, at 7:14 AM, Rowan Tommins > wrote: > > > > On 05/07/2021 11:46, Patrick ALLAERT wrote: > >> Did we ever deprecated something without the immediate intention of > >> removing it? > > > > > > What would that even mean? > > It would mean that although the functions are available and allowed, they > are not recommended[1]. > > > > Surely a deprecation, by definition, is a notice that something is going > to be removed. > > I know that you, and others on this list, have chosen to define > deprecation as including removal, but that is actually not the accepted > definition on the web, nor is it in any way a requirement, it is just your > preference. > > Indirectly from Wikipedia and voted as the top answer on StackOverflow > here[2] (emphasis MINE): > > "deprecation is a status applied to software features to indicate that > they should be avoided, typically because they have been superseded. > Although deprecated features remain in the software, their use may raise > warning messages recommending alternative practices, and deprecation MAY > indicate that the feature will be removed in the future." > > So I am arguing for the legitimacy of retaining "deprecated" features if > their removal would cause significant BC breakage, I'm not just trying to > be a pendant. > > -Mike > [1] https://whatis.techtarget.com/definition/deprecated > [2] https://stackoverflow.com/questions/8111774/deprecated-meaning > Hi Mike, Your links speak *in general*. However this is *specifically for PHP*: https://www.php.net/manual/en/errorfunc.constants.php#errorfunc.constants.errorlevels.e-deprecated-error (*emphasis* mine) E_DEPRECATED: Run-time notices. Enable this to receive warnings about code that *will not work in future versions*. As for "significant BC breakage", isn't that what major versions are for? (and with the current release plan, 9.0 would be for end 2025, i.e. 4 years after 8.1) Regards, -- Guilliam Xavier
Re: [PHP-DEV] [VOTE] Readonly properties
Le jeu. 1 juil. 2021 à 12:23, Nikita Popov a écrit :
> Hi internals,
>
> I have opened voting on https://wiki.php.net/rfc/readonly_properties_v2.
> The vote closes 2021-07-15.
>
> See https://externals.io/message/114729 for the discussion thread on this
> proposal. I think a decent tl;dr is that readonly properties as proposed do
> not play well with clone-based withers, so some people believe we should
> either improve cloning first, or introduce asymmetric property visibility
> instead, which does not suffer from this issue.
>
> Regards,
> Nikita
>
With the proposed implementation the following class:
class A {
public readonly string $name;
public function __construct(string $name) {
$this->setName($name);
}
public function setName(string $name) {
$this->name = $name;
}
public function setName2(string $name) {
$this->setName($name);
}
public function setName3(string $name) {
$this->name = $name;
}
}
Would behave like this:
$a = new A("Initial name");
echo $a->name, "\n"; // echoes Initial name
$a->setName("New name"); // Allowed ?
echo $a->name, "\n"; // echoes New name
$a->setName2("Yet another name"); // Allowed ?
echo $a->name, "\n"; // echoes Yet another name
$a->setName3("Yet another name"); // Not allowed, although identical to
setName()?
I find the word "scope" very confusing to understand in:
> A readonly property can only be initialized once, and only from the scope
> where it has been declared. Any other assignment or modification of the
> property will result in an Error exception.
Is the above behaviour an implementation bug or does the RFC implies that?
Regards,
Patrick
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
> On Jul 5, 2021, at 7:14 AM, Rowan Tommins wrote: > > On 05/07/2021 11:46, Patrick ALLAERT wrote: >> Did we ever deprecated something without the immediate intention of >> removing it? > > > What would that even mean? It would mean that although the functions are available and allowed, they are not recommended[1]. > Surely a deprecation, by definition, is a notice that something is going to > be removed. I know that you, and others on this list, have chosen to define deprecation as including removal, but that is actually not the accepted definition on the web, nor is it in any way a requirement, it is just your preference. Indirectly from Wikipedia and voted as the top answer on StackOverflow here[2] (emphasis MINE): "deprecation is a status applied to software features to indicate that they should be avoided, typically because they have been superseded. Although deprecated features remain in the software, their use may raise warning messages recommending alternative practices, and deprecation MAY indicate that the feature will be removed in the future." So I am arguing for the legitimacy of retaining "deprecated" features if their removal would cause significant BC breakage, I'm not just trying to be a pendant. -Mike [1] https://whatis.techtarget.com/definition/deprecated [2] https://stackoverflow.com/questions/8111774/deprecated-meaning -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
On 05/07/2021 11:46, Patrick ALLAERT wrote: Did we ever deprecated something without the immediate intention of removing it? What would that even mean? Surely a deprecation, by definition, is a notice that something is going to be removed. There used to be an E_STRICT category, which expressed a rather vague "you probably shouldn't do this", but I'm not sure who it really helped. If you want to encourage people to use alternatives to strftime() but not remove it, here are some more productive steps: * Improve the strftime() documentation to point out what those alternatives are, and why they're better * Improve the documentation of those alternatives with examples of the things that strftime() is commonly used for * Improve those alternatives themselves so that they're as easy to use as strftime() Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
Le lun. 5 juil. 2021 à 11:43, Dmitry Stogov a écrit : > Return void by reference should be disabled (not deprecated) > I second that.
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
Le mer. 30 juin 2021 à 11:32, Nikita Popov a écrit : > Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The > vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion. > > Regards, > Nikita > For reasons that Nikita expressed ( https://externals.io/message/113657#114033) in the discussion thread, I wish strftime() and gmtstrftime() would be deprecated, BUT NOT removed in PHP 9.0. Did we ever deprecated something without the immediate intention of removing it?
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
Hey Nikita, On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov wrote: > Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The > vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion. > > I'm totally **for** deprecating `get_*class()` implementations when called without arguments, but I feel like many folks are voting "no" because: * there's no 1:1 migration suggestion in that section * the section states " `get_class()` is approximately the same as `self::class`", without saying what "approximately" means I can imagine that removing `get_called_class()` could also yield some engine improvements in future, as there's also less "magic information about caller scope" to be retained. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [VOTE] Readonly properties
Le jeu. 1 juil. 2021 à 12:23, Nikita Popov a écrit : > Hi internals, > > I have opened voting on https://wiki.php.net/rfc/readonly_properties_v2. > The vote closes 2021-07-15. > > See https://externals.io/message/114729 for the discussion thread on this > proposal. I think a decent tl;dr is that readonly properties as proposed do > not play well with clone-based withers, so some people believe we should > either improve cloning first, or introduce asymmetric property visibility > instead, which does not suffer from this issue. > > Regards, > Nikita > Hi Nikita, As much as I wish I could access publicly a property, but being denied changing it: var_dump($object->property); // allowed $object->property = $newObject; //disallowed I feel that the "readonly" feature will be used instead of asymmetric visibility as suggested in "property accessors" RFC in cases where the latter would be more appropriate. I wish "Property accessors" RFC would have been open to vote for 8.1 as you probably initially intended to for the following reasons: - It doesn't suffer from the clone-based withers issue. - It provides a way to declare properties in interfaces. Maybe there are other drawbacks with that one that I don't see? Probably the much higher complexity of it? Although they are different concepts, I'm not sure we would benefit much from "readonly" if we already had property accessors. Just wanted to express my preferences. Thanks for all the work! Regards, Patrick
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
Return void by reference should be disabled (not deprecated) On Wed, Jun 30, 2021 at 12:32 PM Nikita Popov wrote: > Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The > vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion. > > Regards, > Nikita >
